Making XMOS really Open will build community, reduce delays

[russf]

After providing clarifications to the first two responses, most of my cards are on the table, but I have a question...

I notice that Jason, Folknology, Andy, and Interactive_Matter do not touch on the question of ticketing. Is that an oversight, or do you not see my point?

That is a critical area. At least as important as open repositories, because ticketing is the interface between XMOS and its customers about the issues they are having. (OK, some feedback is provided on the forum, but there is no guarantee of that, and forums are fragmented and hard to search.)

Since it's the issues that take up the majority of time in software and hardware development, and often its the issues that make a product fail, or a project run over budget, one could argue that handling of issues is much more important than repositories. When we raise a ticket, it's because we are in trouble. And when we are in trouble, we want to see if someone has already raised a ticket for the issue, and if we can provide more data, or find out what's happening to solve the issue. Perhaps the ticket was closed by simply emailing a patch, or some simple information to the customer. That information is in the secret ticketing system, and nobody else can see it. Hmmm!

Several reasons are offered to justify ticket systems that are not open. The only ones that hold water relate to private IP and security. These are obvious, and I have no argument with them.

We could go into this in depth, but most of the other reasons can be traced to

• The desire to hide poor quality or a ticket backlog
  The desire to conceal the size of the team
  The desire to keep unflattering features of the organization from the light of day

So, a couple more questions to hardware and code developers:

• How many times have you wanted to know if a question had been raised on a ticket and answered?
  How many times have you not bothered to raise a ticket, feeling you were wasting your time?
  Have you ever raised a ticket that was not taken seriously? If so, how can you prove it?

And to XMOS marketing:

• How can you prove that you support your customers well?
  Have you ever looked at the list of open and closed tickets?
  Is support prioritized in your organization? OK, then what's the average lifetime of a ticket?
  When tickets are solved by email or phone, do you incorporate those answers into an open knowledge base?
  Do product managers track the tickets against their products?

Thanks for all your contributions so far. I'm very interested to know more about your experiences of using the ticket system, whether you are inside or outside XMOS.

Thank You to XMOS for providing this venue for discussion.

Best wishes to all,

--r

Kaizen is our goal,
Fearfulness yields to knowledge,
A flower blossoms.

[russf]

It occurred to me to check around and see what statements XMOS has made regarding openness.

I quickly found this page

I comment on some interesting and relevant points:

XMOS fully understands and supports the principles of open innovation.

XMOS is committed to demonstrating openness in four specific areas – tools, software, hardware board designs, and support for community projects and entrepreneurship.

Opening designs, providing (good) code, tools, and support make a lot of sense.

Finally, XMOS is committed to the principles of open community collaboration – enabling exploration, creativity and entrepreneurship to develop. XMOS created the XCore Exchange website (http://www.xcore.com) as a place for developers, amateurs, entrepreneurs, academics and businesses to come together to share ideas, projects, products, and connect with other individuals with a common interest in the XMOS technology.

XMOS is exploring how to support open-source software and hardware development projects, hackspaces, academic programs (http://www.xmos.com/uni) and welcomes input from individuals with ideas of how XMOS technology can benefit open development.

Can XMOS push this commitment and exploration forwards a little?

--r.

Flowers warmed by sun,
Bees arrive as petals part,
Nectar hides within.

[Folknology]

I think the use of a separate closed ticketing system in preference to an open community ticketing system here on Xcore is also covered in this thread about recent updates to afore mentioned closed system. In fact it extends to all of the features of the info system not just ticketing, not to mention the madness of duplication, maintenance and ambiguity it creates.

Its worth remembering that information only creates value when shared with those who can benefit from it. If one considers information an investment (via resources invested for example) then the best possible return on that investment is only realised through the greatest sharing of that information with interested parties, normally one's customers/community.


*Note Xmos are asking for thoughts about using 2 disparate systems on that thread, its worth making your thoughts known and providing some feedback.

regards
Al

[Interactive_Matter]

After providing clarifications to the first two responses, most of my cards are on the table, but I have a question...

I notice that Jason, Folknology, Andy, and Interactive_Matter do not touch on the question of ticketing. Is that an oversight, or do you not see my point?

Ok, I confess ticketing was too easy for me ;)

I work in my daytime for a software vendor. We have the same problems of openeness against protecting information.

I think the best way is to have both:

Open ticket systems may publish information about customer projects, which have imlications for the customer projects. E.G by the kind of tickets a certain company is issueing you can deduct the projects they are working on. Or the customer wants to prived proprietary code, which should not be public viewable.

I think this is ok.

How do we handle it in my company (or at least try)?

We have public and private tickets. Public tickets can be seen by anyone (as long as it is a customer or partner), private tickets can only been seen by the requester company and my company. By default the tickets are open. If a customer issues a ticket it is private. If the ticket is relevant to other customers too it gets copied as a public ticket and all critical details are removed, so that you can see the issue but not who came up with it.

I think this is the fairest balance between openess and protecting valueable information.

Please do not set up two ticket systems. Instead select a ticket systems which has visibility per ticket. It is more flexible.

If you are concerned about revealing internal information about team sizes, team members - hide the names. It is ok if the names of the developers/engineers are only visible to XMOS and the customers.

[RogerH]

And a happy medium might be:

Open Forum, Closed Ticket system and Open Ticket problem/resolution summary.

That way we could search the Ticket system for Problems and resolutions. The Tickete summary would be written such as to keep any project/commercially sensitive material private.

Regards, Roger...

[Joerg]

Russ,

thanks for kicking off this discussion - and "putting most of your cards on the table". Your comments show that you care - and the responses show that others do too. Thank you.

XMOS has traditionally followed an open source approach and some of the requests expressed on this thread go significantly beyond our current practices. Adapting our current open source practices to support the needs of our broad and diverse user and customer base is an ongoing process. Thank you again for sharing your viewpoints on this this thread - please be assured that we are very carefully listening.

In that context, this thread has attracted a significant number of views (430). It would be great to hear from additional forum members what would and would not work for them in terms of open source repositories and open/closed ticket systems.

Lets keep the discussion going and together find the best solution for all involved.

Joerg

[russf]

Thanks, Joerg. I appreciate your response.

Thanks also for understanding that I'm not sniping for the sake of it. I've done some XMOS development. I have recently started prototyping something new based on G4, and want to do more. I'm in a position today where I must make decisions that will affect my business, and that of my clients.

It's a serious topic, and I need to feel comfortable that everything lines up before asking others to make an expensive commitment. I'm trying to persuade XMOS of the benefits of what I'm suggesting, but in the end, you will do what conforms to the world view of your organization.

I have been a little surprised that more people have not chimed in on this thread. Yes, I know that my posts were long and detailed -- sorry about that -- but I would have expected a bit more vigour in the discussion. I suspect that your presence on the thread will encourage others to speak freely, so thanks again for that.

Most of all, I want to see a vibrant XMOS community being able to easily contribute a thousand tiny improvements, and move beyond the status quo. I've seen it done elsewhere, and want to see it here.

With kind regards,

--r.

[tautic]

Russf,

I read through your blog post, and you do make a valid point. One of the things that first attracted me to the XMOS architecture was what seemed like a strong open source foundation, and a community to back that up. I am pretty new to the XMOS world, but so far, I can't say they haven't delivered that.

On your point regarding github or the like, you presented a pretty strong argument for XMOS to create a software repository which the community can participate in. Reading over the licence agreement for the TCP/IP stack, the license agreement is a pretty standard open source type license. There's nothing stopping any of us from posting/publishing the code to an online source repository, and maintaining our own version (Have to retain the copyright notice of course) - right along with build in ticketing specific to the code, which I think satisfies your other point.

If anyone else agrees, I'm more than happy to start a project over on Google Code that we can start interacting with. If this gains enough traction, it wouldn't surprise me if either XMOS adds capability for XCORE.com to interact with that repository (They've got a pretty nice API for it), or creates their own. Getting some kind of software repository interaction attached to the project hosting here on XCORE.com seems like a logical next step - lets prove it works.

What do you all think?

Best Regards.

[russf]

Russf,

I read through your blog post, and you do make a valid point. One of the things that first attracted me to the XMOS architecture was what seemed like a strong open source foundation, and a community to back that up. I am pretty new to the XMOS world, but so far, I can't say they haven't delivered that.

On your point regarding github or the like, you presented a pretty strong argument for XMOS to create a software repository which the community can participate in. ...

If anyone else agrees, I'm more than happy to start a project over on Google Code that we can start interacting with. If this gains enough traction, it wouldn't surprise me if either XMOS adds capability for XCORE.com to interact with that repository....

What do you all think?

Best Regards.

Thanks Tautic, I really appreciate your support on the issues.

However, I don't support your suggestion of making a separate external repository, although I fear that it may come to that, and we would all suffer from it.

First of all, it's trivial to setup a repository for XMOS code. Any of us could do it. And, much worse, all of us could do it.

Look here http://github.com/XMOSCookbook and you'll find that I did it in June too, but of course, XMOS was not on board, therefore they published improvements elsewhere, which fragments and distracts us from the goal of working together, all providing tiny fixes or improvement, or all bringing our brainpower to solve bigger issues.

The most important point is that XMOS and its users must talk together in the common language of code, about what makes sense to evolve the codebase. Fragmenting into a thousand tiny repositories turns out to be the wrong way to do it.

The only way that makes real sense is for XMOS to bless a shareable repository (github would be fine), or they can install a server wherever they like (waste of time and money, IHMO), setup some rules, and nominate a venue for tickets. Then we can start to assess what bugs exist, vote on what to fix, add test code, suggest fixes, take credit for fixes, build, and make progress.

Nobody has made a single pull request to my repository, and I would probably not make a pull request to yours, for the same reason -- we don't want to inject our creative juices where they will come to nothing. None of us has the resources to waste, but we will rally around a leader.

It's up to XMOS to take the lead, and I am very disappointed to see no real movement from XMOS to take up that role.


I suspect that there are people within XMOS who understand what could be done, but either they have too few resources, or they are overruled by more conservative management. I find this very sad. Software development is blossoming, and "Software defined Silicon" should do the same.

I would love to hear from people within XMOS about this. Apart from Joerg who contacted me about contacting me, the silence is deafening.

--r.

[tautic]

That's a valid observation. Joerg mentioned that this post is getting traction, and that they are "carefully listening". Hopefully more people will speak their minds around this - there is certainly a ton of potential.

The XCore community is great, and i'm looking forward to participating, and concepts like this can only build a stronger community, and a stronger code base for its members to utilize and ultimately improve on. It's not really a totally new concept in the software world, but I haven't really seen this done on this type of architecture (i.e. microprocessor) Are there any other vendors out there also giving out truly open source code like this? I wonder how they handle this type of change control, and bug ticketing. I know of one other vendor, which I wont mention, that has a pretty large TCP/IP stack implementation. Their code is distributed, but it is anything but open source. XMOS is already taking huge steps forward in this arena IMO.

Perhaps there is some concern around additional investment of time which might be required to maintain these code projects if a repository were to be built.

If we do get such a repository, it wouldn't surprise me if the vast majority of code is member submitted and maintained. I.e. let XMOS focus on the technology, and it's users focus on the implementation.