All material on PicaWiki? is PrimarilyPublicDomain?.
The Pro-am Internet Communications Alliance is a hypothetical organization.
"Pro-am" stands for [ProAm? "professional-amateur."]
The goal of PICA (pronounced "pika," as in "pikachu") is:
To make it perfectly clear: this is a mini-IETF, complete with numbered documents and all.
PICA attacks the problems of
Okay, so we found those groups, and it was good. By working on SubPathetaEdit, we collected all (as far as I know) of the energy into rewrites. At least we all know each other- at the very least. CoEd?, as far as I know, (@DATE@), is the one holding the torch. crschmidt and Eloquence abandoned their work, I think the LEO guys are still working, but within Leo, and I think CoEd? is holding it right now; that's thecrypto. If you want details on this subject, talk with me, or one of them, we'll fill you in on the details. I like Palimpsest, I think that's the way to go.
Other story: General Text Filter.
I looked around. Didn't find anything. I thought, "DAMN! This is a great idea!" I'm shocked that there isn't anything! Looked all over the place, didn't find it. It costs so little to make. I just went ahead and started doing it.
And then, I found XmlRpcFilteringPipe?! I told everybody, with lots of excitement! Holy Shit! There's one already! And what's more, it had 2 plugins for it already! That is, a Movable Type plugin, and a Bloxsom plugin. What's more, it already worked with Twiki's, because it was implemented in Twiki. (Or at least, it was; I don't know if it is now.)
We had to do a little work improving the plugins, they weren't totally up to spec, and they had hard-coded links to URLS, but we fixed them up, and promoted the standard. It was only like 4 lines of code to adapt my existing code to the discovered format, and I did so. Piece of cake, and now, we have a bunch of plugins and working servers. It's wonderful.
It was really surprising, because our respective specs were near-identical. The only difference, was I had thought to put in a self-documentation system, and Les had thought to put in a content type. I dumped the doc system, and incorporated the content type. Wonderful. It just works.
Now, we are in the process of making an HTTP Post mechanism, instead of XML-RPC. There is only one delimma left, and I think I'm going to just take the lead, say, "It's this way," and start implementing. Nobody really cares about which way the decision goes, it's kind of dumb to be hung up on it. I think everyone just wants to see it go forward now.
I keep thinking, "This should all have been done at least 2 years ago." Why didn't it happen? Because there was nothing like PICA. It's just haphazard, "here's an idea, does anybody like it?" And of course, the response is: "no," or utter silence. I'm sorry, that's just the way of things. That's just how people respond to stuff. Like everyone's got a veto card. There's no use in hating it, or dislike it, you just have to find ways around. Otherwise, nobody will implement anything anywhere. Sad fact.
The PICA track would include things like:
I suspect that many of the formats are too cool for us, but it would be amazing to see things like XML-RPC, DOAP, Blogging APIs, MarkDown?, etc., join forces with us. That said, it is not our aim. Our aim is to find people who want to work together with us, and write our software together. Should that set of people share that aim, then we would want to work with them. If not, then oh well, too bad. No hard feelings.
Consider:
None of these fit our niche, for various reason.
There are "pro" efforts in our space. They hate each other. They scare me. They are not Pro-Am, they do not like the phrase "Pro-Am," they don't want to be anywhere near us.
As Lion said: " They are viciously fighting against each other. I mean, have you seen it? It's positively bloody. I was walking by Dave Winer the other day, and it was like: BLAM! BLAM! BLAM! CZ-75. Guts everywhere! Absolutely disgusting; Horrible. Trust me: You don't want to go there.
Part of the reason I am encouraging things like the efforts of artists and manifesto writers, is to keep it lighthearted, and friendly, and joyous. Things like that. "
I think that the IETF process is way too big, and way too formal, for our immediate purposes. Once we have some solid stuff, and it's implemented and people have seen it, and even people outside PICA implement it, then we can start talking IETF standardization. I'm astonished that ATOM made it! I think that means that IETF consideration, and eventual approval, is a reasonable thing to expect.
Sure, and while each of these might have a one or two specification discussion on them, none of them are focused on formalizing and providing exposure for new specifications of all sorts. See "what needs will PICA meet?" and "What functions will PICA provide?", above.
Developers would provide:
Everyone would provide encouragement, support, their ideas, energy, and protocols. People who are not developers are invited to participate, contributing their enthusiasm, encouragement, ideas, publicity, translations, and art.
This will happen just like it used to --- their supporters. However, with PICA, a good proposal will have more visibility, making it easier to gather supporters in the first place.
The way I imagine it, PICA would have an explicit membership. Like the IETF, only individuals are recognized. Corporations, governments, and organizations cannot be members. However, a sufficiently advanced artificial intelligence with a distinct identity could conceivably be a member. Anonymous individuals could be members, provided that the member meets the entrance vote.
PICA documents (the equivalent of RFC's) could be:
I'm thinking: Call the documents "POI" documents, for "Point of Interest." The acronym is pulled from my book. It is completely arbitrary, it could be anything. Just not RFC, PEP, JEP, or ISO. (They're taken.)
I would say: Encourage the use of HTML, PurpleNumbers?, PlainTalk?, and VisualLanguage?. Perhaps permit smileys where appropriate, though that's likely not our spec documents. Maybe manifestos. We leave ASCII to the IETF. They are 133t. We are not. (Yet.)
For some historical perspective on all this, I recommend reading, say, RFC 6. Un hunh. Or, say, RFC 3, which I found particularly illuminating. Mmm-Hm. Constrast RFC 2223. This isn't to throw stones: We absolutely love the IETF. If we're lucky, PICA documents may go on to become IETF documents- like ATOM did!
But I perceive the need for our own, independent, baby RFC track.
You all know that I dislike mailing lists; They are closed, they are difficult to work with, you have to send mail and confirm a bunch of junk in order to even get off the mailing list; all the usual LimitationsOfMailingLists?. I'd say: Use a BB Bulletin Board. Ideally, we'd have a static site and a wiki as well. There'd be an IRC channel, ChumpBot?, and whatever stuff we end up creating ourselves.
Acceptance does not require a majority. It requires only the collective endorsement of N people. I am taking N to be something like 10-20 people.
Why do we choose some N number of people?
Who would initially participate in PICA? I imagine most everybody here, interested in seeing these technologies go forward. I imagine Sean Palmer, Aaron Schwarts, and Cristopher Schmidt may be interested. I imagine Les Orchard may be interested. I imagine that various wiki developers may be interested- I have met some who are struggling to find acceptance and interoperability for their whatever-it-is that they have made. (I'm immediately thinking: "Xwiki has some really incredible stuff for making collaboratively produced data structures and databases a reality.")
I have noticed something in my mind: When I start writing down my ideas, my brain gives me more ideas like that. It's like my brain goes: "Hey! You're paying attention! You like that? Here, let me give you some more."
I believe it will be the same way with PICA, and developers. People will wake up, and go, "Wait! You care? You accept implementations?! You guys ROCK!"
It'll be beautiful. :)
I think we'll see a lot of victories in our first 2-3 years. I think that people will recognize: "WHoah! These guys are getting things implemented! Look at how that software works together with that software! Isn't that amazing? Sure, that formats a little funky, and that thing over there is just butt ugly, but overall, look at that!"
Also, we should not underestimate the role of the non-PICA members: They are likely to implement the best ideas from within PICA, magnifying what they saw in there. They will adopt PICA standards that they like, and thus, PICA standards will gain some reknown.
Then we can say, "IETF, we present this experimental standard."
Look: As this develops, all those people who have dreams, all those people who have ideas, will be attracted to PICA.
(this post to the old CommunityWiki? page was deleted b/c it was not public domain)
Here is what we need to do next to make this happen:
After these steps are complete, we can begin deciding how to carry out the actual business of PICA (how to do the PICA memo series, what are "PICA endorsed standards", if any, etc).
So, who is going to setup and host the PICA mailing list??
I could set up a PICA mailing list and wiki hosted on the interwiki sourceforge umbrella project. The only downside to this is that PICA is supposed to trancend mere wiki, so the "interwiki-PICA" mailing list name might confuse some people. But we can always move it later. I'd rather start there and move it later rather than waiting months for someone to volunteer to host it elsewhere.
I'm intent on just backing this page up to an archive page, and then redoing it. Take the TechnologyUnion? idea out of it, and then putting in some mechanisms.
I sketched this out recently, here's what I was thinkinging:
One difficulty is: "How do you serve the PICA documents?"
"Why just 20 registered members? Shouldn't it be based on a percent of total membership, or something?"
The idea is to make it quick and easy to make a formal interface specification. The idea isn't to make a standard that everyone must follow. I take the plurality of MP3 and OGG and what have you as my inspiration: It is enough to concentrate sympathetic people around a document. The later steps of putting the documents in a death match against each other- that seems like something that can come later.
It may be impossible to collect 95 of 100 people around 1 format. But it is probably possible to collect 40 people around 1 format, 30 people around another, and 30 people around still another. Then, you can just write adapters to the rest, or let those 3 groups with their good interface specifications write code and duke it out.
The LanguageOfStandardsAndSpecifications? is confusing, and perhaps the word "Standards body" is inappropriate. People will bite each other's ears off over these things, it seems to me. It's a discussion I'd rather not have.
Basically, I just want to see things go forward. We need nice shiny interface specifications. :) People trust them, because there's process behind them. You have to get a bunch of people to read the document, and put their rubber stamp at the bottom of it. That way, you know it's not some thing that somebody wrote at a moments notice on some wiki page some where. When they see the nice presentation, and when the form of the presentation is familiar and comfortable, they feel like they can trust it.
(Eeegh! I just made an argument for plain text! I'd rather not. I believe that, later on down the road, we can probably write up style guidelines for the use of SVG. Make it monochrome, specify valid line widths, whatever. For now, I'd just like to keep it loose- this is a detail, and I don't want to get bogged down in details.)
(this post to the old CommunityWiki? page was deleted b/c it was not public domain)
I am, frankly speaking, floored by your experiences in these various standards bodies. I'm really impressed, and in many ways, aspire to work on projects of similar value.
I believe that we can do useful things (of similar value) from out here in the boonies. Likely less fanfare, likely nobody really notices, but: Every day I see things that need to be done, that nobody's really doing, and that doesn't really require a whole lot of work. (I mean, considering millions of dollars and the grand scheme of things.)
It is like you say:
I like the table, I like the mat on top, I like the napkin drawings, and the laptops out and coding. Duking it out mano-a-mano with Microsoft, IBM, the UN, whoever, doesn't really strike me as all that appealing. And I have no idea where to find a mecha-suit made out of big company, anyways.
The reason we need PICA, (I feel,) is because we are producing documents. Lots of documents. Most of these documents describe interfaces, systems, machinery.
We have two problems:
PICA will solve both of these issues.
The way we've been managing the documents so far has been: Storing them on wiki pages, storing them in e-mail, referring to IRC chat logs, Moon-Edit pages, the works.
Consider:
Incidentally, the one specification that's actually made to be presented semi-professionally: This one specification has received the most interest and development. Greg Schueler found it, and wrote an implementation in Perl.
Why did I specify it and present it nice? Because people were telling me to. "Gee, is this the spec? Or that? Which wiki page am I supposed to look at?" They wanted it clear and unambiguous. When I did, suddenly people took note. Even my own attitude about Local Names changed. So, it is clear to me that there is value in a solid looking clean presentation.
The XmlRpcFilteringPipe? is something that should have been widely implemented like,... 2-3 years ago. I think people just don't know about it, because it's some idea written on some wiki page on Les Orchard's site.
We are producing specifications like mad. There's just so much specification work to do, it's incredible. The limiting factor in getting all these systems to talk together is lack of specification. You know this, I know this, we both know this.
I have discovered that I can code up working implementations very quickly. Many of our tiny specs, you can implement them in a day or two. A month, tops.
The time it takes to get our specifications agreed upon and out the door, though, starts at around 1-2 months. Eh,... well, I'm going into another discussion. But, anyways:
I feel that we would gain a lot of value, as an alliance, if we made an easy system for ratifying our specifications, collecting them together into one navigable space, and presenting them nicely.
We get that social and mechanical system in place, ("PICA, the Cyborg,") and we're golden.
We don't need a ton of documentation. (did you see my recommendations?) Basically, it's just: Anyone who's interested in being a PICA member is a PICA member. You can't be a corporation, you can't be a government. You have to be a person, you have to be interested, you have to be benevolent towards PICA, and you're a member. Casual? Hell yah.
Any group of 20 people who want to pass a spec can pass a spec. Say PICA has 100 people participating in it. 20 people can pass a spec. It doesn't matter what the other 80 think. If 20 people sign on, hey- that's probably worth something. We're not here to quibble and argue, we're here to meet each other, publish specifications, so we can write our codes to agree with each other.
I'm not at all worried about Sun, IBM, Microsoft, whoever the hell. We're incomprehensible to them. I mean, seriously: Can you imagine IBM publishing a PICA spec? They'd lose- what does Chomsky call it... "Credibility." It'd be like the UN deciding to meet in a fort Sakura (she's 4 years old now) made in our living room, in our apartment. It'd be the most rediculous thing you've ever heard of.
I'm not terribly worried about patents and other such things either. If anyone is worried about patents, they should not be writing software right now. Pretty much any project is invariably going to violate somebody's patent. So, if we want to play it strictly by the boundaries of patents, I would just withdraw entirely from writing software. PICA's the least of your concern at that point.
If PICA somehow raises eyebrows, and gets destroyed, where do we end up? Exactly where we are right now: Out in the boonies, completely off anybody's radar. You just start the whole process up again, with a new name. I'd call it: "CHUU."
Here's what happens: Someone gets a cool idea. They go, "Hey! Here's an idea!" Someone else says, "Yah! I had that same idea!" There are big ideas, and little ideas. We want to understand big ideas, and let the little details sort themselves out. After the ideas thought and told, it's time to act. If you find yourself writing papers upon papers, organizing people for the sake of organizing people, or using fancy language and what not, you're dead. You gotta act. In our case, that means: Write code.
Damn straight. I stand by every word.
But, we have to write specifications. And they have to be nice and it would be really good if they were collected. Making specifications that aren't specific is like writing code that the compiler won't eat.
The specifications have to be thought about, people have to buy into them, because otherwise you make errors, which means changes, which means lots of people rewriting the interfaces to their code, which means lack of interoperability, which means it doesn't go anywhere.
So, the strategy I've been thinking is:
That's the idea. Basically.
I'd like to rework the page, including some deletions, but I fear removing ideas that people are attached to. BayleShanks has taken the lead in refactoring, and I don't want to interfere with that work.
So, I'll just rework my previous post into a BulletSummaryBlock?.
(this post to the old CommunityWiki? page was deleted b/c it was not public domain)
Re: "anyone can be a member, but some are registered members": i think that's sort of abusing the standard meaning of "member". I think PICA should have a list of its members.
Also, I feel the membership should be a little tighter. We don't want to be intimidating, but we still want to be serious. If membership has some attached privilages and responsibilities (even as minor as, privilage: saying you're a member, responsibility: sign up; although I think it should be a little more than that), then members will feel more attached to the organization.
A related point: we'll need to have bylaws, and we'll need a formal procedure to amend those bylaws. Which should probably be that the members take a vote of some sort. So, we need a list of voting members at least.
I would propose that membership be much tighter than we have it now (but still not intimidating). I propose that anyone can become a "member", who can do all the main stuff, but that it's slightly more difficult to become a "voting member", i.e. person who sets policy for PICA. I'm thinking that anyone who wants to can become a voting member, except for people whom are considered disagreeable by 1/3 or more of the other voting members.
In great detail:
Why?
This sounds complicated, but it's really simple in terms of "members", which is what matters. And hopefully it wouldn't prevent most people who wanted to become voting members from doing so.
Re: PPD: I just wanted to retain maximal flexibility in case we end up re-using some of the words that we develop on this page as part of PICA -- i.e. in case PICA wants it's bylaws to be PD, but its bylaws use some sentences from this page, etc.
BTW, my girlfriend Katherine had a good idea: we should pronounce it "pike-a", and then use this guy as our mascot: 
he seems to embody our "niche" (as opposed to IETF, W3C, etc)!
On the other hand, a "pica" seems to be a neat type of bird:
so maybe that would be cool too.
To reiterate what Lion already said in reply to Murray's older post:
Yes, this is not really a "standards" organization, this is a "boonies" organization. It's purpose is NOT to define authoritative standards. It's purpose is to assist in the development of proto-standards. Like standards organizations, PICA is basically administrative. It's function is mostly as a SharedAwarenessSystem, to take notes on what is happening. It lets everyone know what has been proposed, and which proposals have a few (>20) supporters.
Timeline for a standard:
So, PICA helps Bob's idea in steps 2-6, long before it is a standard. By the time it's being considered as a serious standard, PICA is no longer involved; now things are handled by the IETF.
Patents: I agree that being sure there are no patent problems is impossible, but we may as well at least make a small effort.
I think that any member who submits a PICA memo, or signs it, must agree that
In addition, any PICA member who is even aware of the submission of a memo for which they know of or should know of (this is shorthand for conditions (1) and (1a)) is obligated to disclose this within two weeks.
All public PICA documents, including memos and bylaws and what have you, should have some standard copyright status, like PD or CC-BY-SA-NC. PICA will own at least an unlimited sublicensable license to all public PICA documents, and will be free to re-release them under any copyright license that it wants in the future, should it choose to do so.
I like the magpie-birdy. They are beautiful, they fly around in my yard in Berlin sometimes and they are known for stealing shiny things which they love for some reasons. Like a spoon or a ring - putting them on your window-shelf they might take it away. Elster in German, diebische Elster, thiefy pica. I won't be of much help for now on the project but I strongly support it. Added my name above, just for making it look better. en.wikipedia: pica, wikimedia.commons: magpie, [1]
