On Wednesday, February 27, 2013 11:05:57 Gina Likins wrote:
A couple questions:
(1) When I sent my first email, I received a private reply that said this:
> ... a reply-to that doesn't point to the list would have been nice...
to which I replied:
> I wish I knew what you meant!
> This is what I was sent when I joined the list:
> "Welcome to the tosw(a)lists.fedorahosted.org mailing list!
> To post to this list, send your email to:
> tosw(a)lists.fedorahosted.org <---- this is where I sent my email
> General information about the mailing list is at:
> If you ever want to unsubscribe or change your options <snip>
I haven't received a response, but I don't want to screw up again in the future,
so what did I do wrong? I sent my email to email@example.com... Was there
something else I was supposed to set in my email (and how was I supposed to know that?)
You didn't do anything wrong. Whomever sent that response was complaining about the
reply-to address set by the mailing list. That is an option configured by the mailing list
administrators, and opinions differ on what the correct way to set that option is. Just
ignore the complaint - you did everything right.
(2) On "The Open Source Way": I am trying to suss out the
intersection between "collaboration" and The Open Source Way. In a function
that doesn't involve development (like Facilities or HR, for instance), how does
working "Open Source" _differ_ from collaborating?
* Does everyone have to agree on a plan to work Open Source? (consensus version)
* Can problems or parts of problems have Owners, with the acknowledgement that owners
need to get input from other people, but that the final decision rests with them? (This
is antithetical to the consensus version
There is no single "right way", but most large projects are going to use a
strategy more like the second approach you describe. Delegating responsibilities down from
the top level is the only way that large projects can avoid being bogged down by
bureaucracy. Allowing individuals or teams to own what they work on is fundamental to the
success of volunteer-driven work and tends to help in any project. At some point, someone
has to be able to make the final decision, and letting the most interested party make that
decision usually makes the most sense. Accepting that opinions will differ and allowing
projects to evolve through natural selection have been critical to the success of many
open source projects.
* I understand the "glass houses" (and think it's
critical to expose your process). Is there a guideline for how "formed"
something needs to be before it's released into the wild for commentary? The argument
could be made that if something is not well-thought out enough, then releasing a
half-baked idea could just cause more confusion -- how do you balance this?
Sure, pushing something that isn't well thought out can cause confusion, but at the
same time, presenting an idea at an early stage will allow others to contribute to molding
the idea in the right direction. It is also not unusual for someone to come up with an
idea but not to follow through with it. If they share that idea, than others who might be
more interested can pick up the torch and see it through.
There is nothing in the open source way that prevents a little secrecy. For sensitive
matters, where you don't want information getting out until it has been refined,
"closed-door" meetings and controlled information access can be used. The
general feeling in open source projects is that these kinds of things should be limited to
where they are absolutely necessary. In general, the "release early, release
often" mantra applies to newly-formed ideas. "Braindumps" and the like are
considered a good practice.
* Programming projects (to some degree) have a built-in "sanity
check," in that Things Will Break if people start messing about with things they
oughtn't to, etc. IMHO, this gives programmers more freedom to see something and fix
it. In the non-programming world, there's no built-in QE function, so people are far
more cautious (it seems) about taking on things that are in grey areas or new areas, for
fear of breaking something (process or relationship). How do you counter that so you can
get to the "release early, release often" model.
How change and innovation are best supported is really very sensitive to context.
Obviously, people are going to be reluctant to start messing with mission critical
processes where failure is not an option. This is not a problem unique to the open source
way. The general answer, put simply, is risk assessments. Leadership must decide what
risks are acceptable, and contingency plans should be prepared.
In programming, the contingency plan when improving existing projects is usually "use
the old version". For new projects, the contingency plan is usually "use an
existing alternative" or "push back the launch date". For non-code
projects, the contingency plans will depend upon the needs being addressed and the options
To encourage people to step into the unknown, the best motivator is usually the end goal,
not some made-up incentive. You get people to take chances by reminding them of what they
These may be questions that are answered online or in literature, but I've had
difficulty finding answers that are about *working* Open Source, as opposed to developing
Open Source. I need some ideas about what Open Source looks like when it's not in an
Thanks for any help on (1) or (2).
As for the difference between the open source way and collaboration in general, what makes
open source different is an attitude of openness and freedom that doesn't always exist
in other collaborative environments. An army collaborates internally to complete its
objectives, but infantry soldiers - the main workforce of an army - have very little say
in how things are done, very little influence on policy and no freedom to explore
different paths or define new objectives.
I'm sure others can chime in with their own thoughts on (2), but there's my 2c.
Patrick W. Barnes
All messages cryptographically signed: