Home › Groups › DIYcity Main Group › The Short Version of That Last Post

DIYcity Main Group

User login

The Short Version of That Last Post

Submitted by John Geraci on 12 May 2009 - 3:30pm to DIYcity Main Group.

For those of you who don't like reading through long blog posts for salient details, here is that last post in bullet points:

• We're trying out a new experiment in which people on the site will work together building open source civic software, then sell versions of those products as iPhone apps.

• The money from the sales of those apps will go back to the builders of the product.

• The underlying code will remain open source i.e. reusable, able to be built on, or distributed as people see fit.

• Nothing else about the site is going to change.

• We will start off this experiment with the two apps we've already got in production, DIYtraffic and SickCity, and maybe also on a third, new project.

• If these trials seem interesting to people and get product built, we will roll it out further.

• We'll begin next week.

Over and out!

13 May16:36

Holy Grail

By jrdesvernay

Hi John,
-------------------------------------------------
DIYCity project for civic software:
1. projects are broken down into discrete tasks on a to-do list 2. anyone can step in and complete a particular task or series of tasks on that list 3. in that way, projects get completed by the group in a self-organizing way 4. anyone who completes one or more task on the to-do list receives a share of any revenue that results from the sale of smart phone applications based on that project
--------------------------------------------------

There's a few main issues I see here:

1)
a) Who will plan the broken down of task: The initiator (you) or the user.
b) can you add more task along the way, and again who could

2) Task evaluation
Some task are more complicated than others, requiring more expertise and more work, in order to assign a fair share of revenue to those tasks, we'll need to quantify those task and rate them by their complexity.

Illustration:
Given a definite list of task, and by their complexity factor, we can assign a % of the total share of the project per task.
for 12 task, 2 would be really complexe and could be rated at 20% each, the other 10 task equally less complicated could be rated at 6% of the project.

Who will decide of the task % : the Initiator, or the users.

3. Again as per 1 and 2 we need to see by who the project structure will be managed.
If we work on a hierachical organisation as in a company, the project manager will abitrarly assign and define those task, if we work in a horizontal organisation then all users will decide.
By looking at the project which organisation work best?

4. As per 2, the main difficulty isn't necesserly to complete the project but how to organise it.

Can't wait what other users think about it.
My best shoot is that given this is a first time, I think we should get the initiator assigning the task and rate them with feedback from user.
We should also fix a deadline for starting the project and break it down.
moreover this type of project sounds like trying to get linux build up by a programing community in a propriatary way.

13 May17:34

Hi jr, Thanks for the

By John Geraci

Hi jr,

Thanks for the comments.

Like you, I'm seeing this working as a combination of hierarchical and flat organization. Though I would like it to be as flat as possible, and only use hierarchy when necessary to give coherence to things.

Task definition: this I think is something that should be centrally managed at some level. I think there has to be some single person defining what is on the list for now or off the list, to give a project coherence. Of course that list could easily be fed by a group-generated list of ideas. There just needs to be one person deciding which of the items on that group list to prioritize.

I would love to be wrong about that - if I am, someone please show me how a coherent product can emerge without any single person controlling the to-do list.

Task evaluation: as I see it, task evaluation should come from the group, and it should come after the fact. That seems like the only fair way to slice it: your work is evaluated by your peers on the project, after the work is done. And any compensation comes out of that group assessment. As long as everyone is on board with that at the outset, I think it should work. I'll post more on this soon in the Discussions group.

> moreover this type of project sounds like trying to get
> linux build up by a programing community in a propriatary way.

I see it more like this: we're building what will become a huge base of non-proprietary code, on top of which we're adding a small proprietary layer with which to pay ourselves and the project, to keep it going and stimulate further development.

Will that work? I don't know. Let's try it out and find out!

I've started another thread on this in the Discussions group, if anyone wants to comment there:

http://diycity.org/discussions/gauging-interest-levels

Would love to get more feedback.

14 May11:10

Re: Hi jr,

By whitneymcn

While I think there are some very different issues that will have to be
addressed with DIYcity, it might be worth looking through some
background on the Apache Software Foundation for some context and ideas,
as well as some of the other big open source projects. They're likely
more/differently structured than suits DIYcity, but there's a lot to be
learned from the successes (and failures) of other open organizations.

ASF "how it works" here: http://www.apache.org/foundation/how-it-works.html

- Whit

14 May14:34

re: apache

By John Geraci

> it might be worth looking through some background on
> the Apache Software Foundation for some context and ideas,

Great read Whit, thanks for posting the link. I especially liked the part about how meritocracy works with Apache. That's something to learn from for sure.

I think another interesting point of reference here is Mozilla, which runs a fantastic open-source product, and still manages to make over $60 million a year by various deals, none of which compromise the integrity of their product. The Mozilla Foundation oversees their product, and the Mozilla Corporation oversees integration of that product with business partners and such.

I'm interested in exploring some sort of hybrid like that for DIYcity: making great open source product, while also leaving the door open to making money in ways that don't compromise the integrity of the product or the organization.