MANIFESTO FOR SUCCESSFUL COLLABORATION

[Russ Ferriday]

This manifesto is based on an exchange between Al Wood and myself, and is the version posted here: 

http://www.xcore.com/forum/viewtopic.php?p=6137#p6137 at 14:00 Pacific time, today.

--r.

MANIFESTO FOR SUCCESSFUL COLLABORATION

Preamble

Each day sees larger fraction of our society's technology infrastructure and commerce becoming influenced by Open Source development. Some of the biggest corporations use and contribute to Open Source software and recommend it to their top-tier clients. The benefits of the Open Source development model to large and small companies, and society as a whole, are well documented [1]. 

Predictably, entities in the XMOS community now wish to collaborate to improve the acceptance of XMOS technologies in their various markets. There is a large potential benefit to XMOS from supporting a vibrant developer community, and there is a similar benefit to community members from being able to use well tested code from the community. 

The nature of XMOS technology makes it a natural nexus for a diverse range of hardware and software technologies. Metcalfe's Law [2] is a useful metaphor to describe this space.

When Open Source development is fostered across the boundary between a predominant Company and a community, fears arise on both sides. Contributors from the community want to ensure that the hardware and software designs, code, concepts and implementations that they contribute remain open and free for use by the community. On the other hand, the Company needs to keep its options open, and protect itself from liability and claims related to community contributions that become incorporated in its products.

These are valid concerns, and there exist several very tangible examples of how to solve them. Without quoting specific documents, one can point at large Open Source collaborations sponsored by Yahoo, Facebook, and Google, and smaller projects such as Zope, and the related Plone, both of which have very lively and successful communities, while still on a scale that mere mortals can still comprehend. 

A recent thread on xcore.com [3] extolled the need for an official open code repository, to capture many small contributions from individuals, and foster the emergence of task groups to improve specific areas of source code already opened by XMOS. The discussion touched on xtcp, and usb code, specifically, mentioning quality and performance concerns, and it was clear that several external potential contributors would rally around an open repository, where they have not rallied in the past around unofficial ones.

All of the well known and successful Open Source projects center their existence around functional and tested code in shared repositories. While it is simple to create shared repositories in the public space, for the benefits laid out above to accrue, the network effect that is created by an official repository is crucial.

The same thread touched on an open ticketing system[4] as an important way to exchange information within the community, and help developers outside XMOS understand what issues will or will not be fixed internally, giving them the option of collaborating to produce community contributions, and also preventing duplication of effort. Open ticketing is rife across the Internet, and companies such as Facebook depend on it for rapid feedback and to engage developers.

Recognizing the enormous shift in perspective required on the part of XMOS to successfully engage with a growing community, this MANIFESTO is designed to bootstrap discussion. In itself this may never be perfect document, but that is not the intent. The success of this document will be measured in the extent to which it brings together a community with a shared purpose, and to the degree that a formal organization emerges to meet the needs of all concerned. This document is just the start...

Call to Action

So, now, formally, the members of the XMOS community, including all users or potential users of XMOS technologies, the company XMOS Ltd itself, and its employees and business partners, are hereby invited to participate in the institution of an XMOS Foundation.

Membership

All members of the the wider XMOS community, including all users or potential users of XMOS technologies, employees and business partners of XMOS, are invited to participate in the discussion, the empowerment of a pro tem board, the agreement of articles of incorporation, and the holding of an election of officers.

Goals

The XMOS Foundation shall represent the interests of the community of users and producers of XMOS technologies, and promote the development of hardware and software designs that help broaden the scope of the XMOS platform, and grow the market for XMOS related products. 

In particular to:

Provide clear, neutral, and sustainable ownership of contributed code.

Provide a decision-making structure for essential community activities.

Interface with XMOS, the company, to represent the needs of the Foundation membership.

Assist XMOS in the transition to greater transparency and openness for the benefit of Foundation members.

Priority Tasks

As a high-priority, the initial board of directors will take steps to develop a simple yet robust legal framework for ownership of hardware and software source code contributions that protects the rights of all contributors, and encourages collaboration. 

The board will immediately foster productive and professional engagement with XMOS Ltd, to determine what role the Foundation can play in the transition to openness. 

To take part in the Foundation Discussion, please join the group here: http://groups.google.com/group/xmos-foundation?hl=en


Notes

The point of the first goal-bullet is to ensure that, as the XMOS eco-system grows, Foundation members can contribute improvements in the knowledge that they will remain usable by the whole community. This counteracts the fear that would exist both inside and outside the community that if members use code or hardware designs in a product, there may be a legal challenge that would harm their business, by causing expensive lawsuits. Anyone who contributed under this agreement would sign their contributions over in perpetuity to the Foundation, and the foundation would protect the rights of foundation members (and non-members) to use that code without fear of legal issues. This is a lot like the role of the Apache Foundation, Plone Foundation, etc.

The expectation is that the foundation would attempt wherever possible to use existing legal patterns, such as those exemplified by the Apache Foundation, the Plone foundation, etc, to reduce duplication f effort, and maximize effort on such projects as improving the technologies, support for collaboration, supporting new technology ports, improving the standing of this technology in the marketplace, etc.

References

[1] This wikipedia article gives a useful history: http://en.wikipedia.org/wiki/Open-source_software

[2] http://en.wikipedia.org/wiki/Metcalfe's_law

[3] viewtopic.php?f=8&t=820

Russ Ferriday -- Systems Architect & Entrepreneur

CEO Topia Systems Ltd.

ru...@topia.com  --  +1 (805) 910 7877  --  www.topia.com

[Interactive Matter (Marcus)]

Hi,

I think there is another field of Open Source Software which is much
more fitting for XMOS.

In the J2EE and Enterprise Web Technology ther are open source
projects like the Apache Foundation or Spring.

Those communities build critical business infrastructure like the
Apache Web Server, the Tomcat Java Web Containter or the Spring
Framework.

Those components are vital for many private (Intra-) or public
(Inter-) web infrastructure. Big companies like IBM are massivley
supporting and funding those projects. The results are much larger
than a single company can achieve. The components developed here are
de facto standards for some enterprise software components.
The collaboration in a Open Source structure has many advantages for
contributors and users:
- No compnay alone would be able to achieve those results, regarding
complexity and quality
- Beeing Open Source ensures the stability and usability of the
results for any of the participants. There is no chance that the
results get closed or discontinued.
- The broad user base enures that problems are quickly fixed and the
basis is stable. It is not perfect and there are of course problems.
But the results are much better than closed source software.

All those effects ensure that the software can be use for critical
business are _since they are Open Source Software_.
I think the strong business orientation of those components, aiming at
big companies. I think many components are part of critical business
infrastructure in any of the Fortune 500 companies (Microsoft might be
an exception).

I think we should shift the focus a bit away from the vivid community
and their needs towards the advantages Open Source can give to XMOS as
company, its partners and customers.
I personalyy think that opnenig up more ensures that critical
infrastructure for XMOS gains quality and development speed, since
there is a community of XMOS employees, partners and experts enhancing
and improving the core infrastructure for XMOS. The high quality
infrastructure ensures that it is easier to build products using XMOS
technology qith a quicker time to market and lower costs. If the
infrastructure is real Open Sources it gives customers and partners
the safety that those components are allways public and a firm base
for their development. It is imposible to simply remove it from the
web site, discontinue it or stop supporting it.

I think those are real, critical business values.

Marcus

[kasbah]

This sounds really good. What it does not address however is the known
problem of documentation. Through community participation the rather
patchy and convoluted series of documents and lack of usage examples
could be addressed. We could realistically start doing this right now
by setting up a wiki and contributing. It could then, at a later date,
be exported to be the wiki part of a public repository and bug
tracking system.

We could take a similar approach with the public repository. Actions
speak louder than words and a central community led repository that
does things better than the xcore project hosting would certainly
attract XMOS attention.

I move to set up something like redmine or trac and clone essential
projects (such as the tcp/ip stack which seems to be mentioned a lot)
and at least pool the community efforts going in to these.

On Nov 16, 10:12 pm, Russ Ferriday <ru...@topia.com> wrote:
> This manifesto is based on an exchange between Al Wood and myself, and is the version posted here:http://www.xcore.com/forum/viewtopic.php?p=6137#p6137at 14:00 Pacific time, today.

[Al Wood]

On 21 November 2010 13:48, kasbah <kaspar...@gmail.com> wrote:
> This sounds really good. What it does not address however is the known
> problem of documentation. Through community participation the rather
> patchy and convoluted series of documents and lack of usage examples
> could be addressed. We could realistically start doing this right now
> by setting up a wiki and contributing. It could then, at a later date,
> be exported to be the wiki part of a public repository and bug
> tracking system.

Xmos already has a wiki of course as part of Xcore, and some examples
and docs have been added by the community including myself, but far to
little of course. For me however source code documentation would be
nice i.e. some commenting in the code, particularly with complex
source such as the network stack. If we wanted to do this more
directly however with say a git repository, Github offer git based
pages which allow a git controlled documentation area written in say
markdown, I have used this already for Amino documentation and more
and more folks are using this feature. So my recontamination apart
from good source code documentation in place (comments) would be to
use Github's pages function as a fork with the source code itself in
markdown text.

> We could take a similar approach with the public repository. Actions
> speak louder than words and a central community led repository that
> does things better than the xcore project hosting would certainly
> attract XMOS attention.
>
> I move to set up something like redmine or trac and clone essential
> projects (such as the tcp/ip stack which seems to be mentioned a lot)
> and at least pool the community efforts going in to these.
>

I vote for github as I mentioned above. In terms of forking we could
certainly do that ourselves but it would be good to at least get an
agreement with Xmos on a module of code that they wouldn't then change
behind their info wall before lobbing another version over.

--
http://www.folknology.com

[Kaspar Bumke]

I agree that the agreement with XMOS would be nice but we should not withold action until we receive it. We seem to be agreed that our own repository hosting and documentation system would be good and I will start a new thread on discussing the technical details of this.

[Kaspar Bumke]

We need to decide wether we should start our own repository and bug-tracker or wether we should give XMOS a chance to respond and open up their own system.

[Al Wood]

On 21 November 2010 16:24, Kaspar Bumke <kaspar...@gmail.com> wrote:
> We need to decide wether we should start our own repository and bug-tracker
> or wether we should give XMOS a chance to respond and open up their own
> system.
>

Ok you have just done so! how much time to we give them to respond 1
day, 1 week, 1 month, 1 year?

--
http://www.folknology.com

[Jayson Tautic]

Once we have a clear definition of the features/functionality that we as the community see necessary to fulfill our goals, Is there any merit in getting as much of us as possible to sign a petition and submit it to XMOS ?

Jayson Tautic

[russ]

Thanks for raising this, Jayson.

Presenting a petition might give XMOS the false impression that they
have a choice about doing-the-right-thing.

Based on the fantastic responses I've seen here in the past few days,
and the amazing enthusiasm, even in such a small group, I believe we
should try to make the most open and XMOS friendly steps we can. We
should feel secure that we will grow as an organization, we will help
XMOS with its goals, and hope for a rapid convergence on a more
efficient path in the near term.

We don't need to beg permission for any of that.

And I am very encouraged to hear that XMOS is watching us closely.

Things could not be going much better, IMHO.

Best wishes to all,

--r.

On Nov 21, 9:02 am, Jayson Tautic <jtau...@gmail.com> wrote:
> Once we have a clear definition of the features/functionality that we as the
> community see necessary to fulfill our goals, Is there any merit in getting
> as much of us as possible to sign a petition and submit it to XMOS ?
>
> Jayson Tautic
>

> On Nov 21, 2010, at 11:25 AM, Kaspar Bumke <kaspar.bu...@gmail.com> wrote:
>
> We need to decide wether we should start our own repository and bug-tracker
> or wether we should give XMOS a chance to respond and open up their own
> system.
>

> On 21 November 2010 15:37, Kaspar Bumke <kaspar.bu...@gmail.com> wrote:
>
>
>
>
>
>
>
> > I agree that the agreement with XMOS would be nice but we should not
> > withold action until we receive it. We seem to be agreed that our own
> > repository hosting and documentation system would be good and I will start a
> > new thread on discussing the technical details of this.
>
> > On 21 November 2010 14:50, Al Wood <a...@folknology.com> wrote:
>

> >>http://www.xcore.com/forum/viewtopic.php?p=6137#p6137at14:00 Pacific

> ...
>
> read more »

[Al Wood]

On 21 November 2010 19:07, russ <russ.f...@gmail.com> wrote:
> Thanks for raising this, Jayson.
>
> Presenting a petition might give XMOS the false impression that they
> have a choice about doing-the-right-thing.
>
> Based on the fantastic responses I've seen here in the past few days,
> and the amazing enthusiasm, even in such a small group, I believe we
> should try to make the most open and XMOS friendly steps we can. We
> should feel secure that we will grow as an organization, we will help
> XMOS with its goals, and hope for a rapid convergence on a more
> efficient path in the near term.
>
> We don't need to beg permission for any of that.
>
> And I am very encouraged to hear that XMOS is watching us closely.
>
> Things could not be going much better, IMHO.
>

Actions speak louder than petitions..

--
http://www.folknology.com