Making XMOS really Open will build community, reduce delays

Technical discussions related to any XMOS development kit or reference design. Eg XK-1A, sliceKIT, etc.
User avatar
russf
XCore Addict
Posts: 146
Joined: Thu Dec 10, 2009 10:17 pm

Making XMOS really Open will build community, reduce delays

Postby russf » Mon Oct 25, 2010 10:03 pm

On my blog, I posted the text of two tickets I raised today.

I will not repeat that post here. If you feel strongly about making progress using XMOS and XMOS software modules, please go and take a look.

If you agree with any of my points, please come back to this page and make your comments. That way, XMOS will be able to tie your comments to you, the source, and in light of the contributions you have made.

It's time to change the game....

Best wishes,

--r.
User avatar
bsmithyman
Experienced Member
Posts: 126
Joined: Fri Feb 12, 2010 10:31 pm

Postby bsmithyman » Tue Oct 26, 2010 12:23 am

I have some mixed feelings about this, but I think you raise some good points. It would be really nice to have a hosted revision system where users could do more advanced version control than what is included on the XCore site. However, I think it's fair to say that individual users can and have done this for their projects, and that there are lots of (free) options available.

I suspect that part of the reason the XMOS ticket system is closed is for intellectual property and privacy reasons. Especially for industry users, there needs to be a way to talk to XMOS developers without it being shared to the whole world. The industry will not adopt the XCore chips if they can't expect certain discussions with their supplier to be private. I think XMOS has done a pretty good job of setting up the XCore community to cover discussions about the open side of things. So I think I might disagree slightly with what you're saying, but perhaps suggest that it should be possible to mark your ticket as public if you so choose.

Of course, I could be totally wrong in my assumptions, so perhaps Jason or another person involved in the ticket system at XMOS could comment? Would it be possible to have a public ticket system while still preserving the advantages of the current setup?

Cheers,
Brendan
User avatar
Andy
Respected Member
Posts: 279
Joined: Fri Dec 11, 2009 1:34 pm

Postby Andy » Tue Oct 26, 2010 12:48 am

russf wrote:On my blog, I posted the text of two tickets I raised today.

I will not repeat that post here. If you feel strongly about making progress using XMOS and XMOS software modules, please go and take a look.

If you agree with any of my points, please come back to this page and make your comments. That way, XMOS will be able to tie your comments to you, the source, and the contributions you have made.

It's time to change the game....

Best wishes,

--r.
I'm not sure I completely agree with the points you raise. Most of the industry use a closed ticket system for obtaining personal support on issues - any feedback on more general issues that might be of benefit to the whole community tend to be handled in the knowledge base or on a public forum, such as this one.

In terms of the software modules, I don't think there's anything stopping the community collaborating on changes that might benefit the software quality. A public free-for-all repository of the modules might be useful but I can't see how XMOS could ensure the quality of such an offering.
User avatar
russf
XCore Addict
Posts: 146
Joined: Thu Dec 10, 2009 10:17 pm

Postby russf » Tue Oct 26, 2010 3:37 am

bsmithyman wrote:I have some mixed feelings about this, but I think you raise some good points. It would be really nice to have a hosted revision system where users could do more advanced version control than what is included on the XCore site. However, I think it's fair to say that individual users can and have done this for their projects, and that there are lots of (free) options available.
Thanks Brendan.

I think you are confusing a few issues. My goal is not that XMOS provide a repository for MY code, but that they provide a controlled way for us all to track changes and provide input to THEIR code. We should all be creating layered systems, these days. My code belongs in my layer, unless it belongs in a layer beneath AND has value to other users. This approach is the way that Open Source developments become incredibly valuable compared with closed source projects. If I can provide a few tiny improvements or extensions, in a controlled way, to XMOS code, and several of our friends do the same, we all benefit. Also see more detailed comments below about the benefits of open repositories in increasing release quality.

BTW: If you are looking for repository hosting. It's simple. Go to GitHub.

Andy wrote: I'm not sure I completely agree with the points you raise. Most of the industry use a closed ticket system for obtaining personal support on issues - any feedback on more general issues that might be of benefit to the whole community tend to be handled in the knowledge base or on a public forum, such as this one.

In terms of the software modules, I don't think there's anything stopping the community collaborating on changes that might benefit the software quality. A public free-for-all repository of the modules might be useful but I can't see how XMOS could ensure the quality of such an offering.
Thanks for your comments, Andy. You raised some good points.

The issue of "personal support" is an important one. However, I suspect that most tickets are more general in nature, and probably relevant to many. For example, today I added a Me Too comment to one of Folknology's posts from about 11 months ago on the forum. If that had been posted only as a closed ticket I would not have known that someone else shared my issue, and may have hesitated to confirm it or describe it.

Knowing that others share an issue is very helpful. It gives you a chance to collaborate on a workaround; it saves time researching; and an existing ticket provides a useful collecting point for confirmation and additional information for developers. Without an open ticketing system, the vendor needs to find the time to merge duplicate tickets -- a difficult, error prone, and labour intensive task, that frequently ends up with people not notified, and bugs being dropped. And the fact that a large part of 'the industry' does things one way, does not make it right. A large part of the industry still uses Internet Explorer, when there are browsers for free that are better in every single respect.

Secondly, it should be remembered that a large slice of good software these days is Open Source, and these projects manage quite well with open ticketing systems. Some of them provide a secure option for private or security issues that are not to be posted publicly until a fix is released. And some closed-source companies still have open-ticketing, because it makes soooo... much sense. I'll cite Facebook as a starting point.

Examples of open ticketing
and here is a list of bugzilla's bigger customers including Mozilla itself, NASA, and a list of linux distros.

I concede that there is an embarrassment factor in hanging out your dirty laundry, but some significant organizations have managed to deal with this. I think XMOS is mature enough, too. OTOH, I would be embarrassed to see my company's development and the potential contributions of dozens of competent customers/engineers hindered by out-of-date attitudes and old fashioned practices.

Thirdly, the forum is a spectacularly BAD place to track bugs. This particular forum software has no cross-forum search, so I to search across sections I must do a google site:xcore.com search. Many don't know about this google feature. On the forum, I can't look for bugs by status, severity, date, or if they are assigned, if they were from me etc.

Coming to the repository point: I disagree completely. It's a complete waste of time to have a public free-for all repository. This amounts to a fork of the project, and puts an even bigger load on the internal developers. It's very unlikely that either internal or internal developers would find the significant time to merge changes across repositories, and the result would be worse, not better. And yes, XMOS would not be able to ensure quality, simply due to manpower and lack of control. There is a level of effort and discipline to managing a repository. My model has XMOS providing this effort, in return for engaging the help of its customers in improving their product.

Since you mention quality... It is a quality issue that brings me to this topic in the first place. A good source repository, such as git, lets me offer tests back to the developers to illustrate a bug I have detected. Those tests can be merged with a growing test-suite under full control of XMOS, for example, prior to working on a fix. Another example: you or I could develop fixes on a branch from the trunk, so that an internal developer or other customers could confirm our fix and recommend a merge with trunk (or a git pull). Groups of developers outside XMOS could work on a development branch to contribute a new feature. The community could help prove the quality and compatibility of the changes and features BEFORE they were merged and released by XMOS. Compare this with the more haphazard method of keeping silent as bug fixes accumulate, then testing them and lobbing them over the wall in a zip file. Further bug fixes won't be released until the next time.

There is a widespread and well-tested method in use on many typical repositories. Fixes are tested on a branch, merged to HEAD, and then tested for release. The majority of users take only the released code. More advanced users use HEAD code and are then able to immediately test fixes that were made for their needs. Newly introduced bugs are often found BEFORE general release because testing across a wider audience starts so much earlier.

All of these changes work in favour of quality, not against it.

The fact that you "can't see how XMOS could ensure the quality of such an offering" ignores the fact that quality is assured trivially by dozens of organizations every day, who maintain mission-critical software, that moves at a much faster pace than XMOS components, all on the basis of open trackers and/or open repositories.

My request is that XMOS adopt a well proven, perfectly rational, business-and-privacy-compatible way forward for ticketing and all released code. I fully understand that some source may still need to be kept closed.

C'mon XMOS, let's get over the closed-repository/closed ticketing era, and sell some silicon. We all have some skin in this game.

--r.
Last edited by russf on Tue Oct 26, 2010 4:03 am, edited 1 time in total.
Reason: Added reply to Brendan's post. Tweaked last para.
User avatar
jason
XCore Expert
Posts: 577
Joined: Tue Sep 08, 2009 5:15 pm

Postby jason » Tue Oct 26, 2010 11:45 am

Hi Russ,

Just to understand things more thoroughly, apologies if I am slightly off track, but I want to understand your vision and have a few questions upon looking at the posts:

- What is stopping the community from taking the existing code, making a GitHub repository, and then maintaining and developing that in to something amazing?

- If the above is not what you envisioned, then could you explain a bit more how this would work. If you were to start at XMOS tomorrow in charge of taking on this project, what would you do? How would you satisfy customers who do not want to use OpenSource code (they do exist) - do we then have 2 versions? One open source, one closed? If that is the case, how is that different to my first point?

Apologies if I have missed the point, please do point me in the right direction.

All the best,

Jason
User avatar
Andy
Respected Member
Posts: 279
Joined: Fri Dec 11, 2009 1:34 pm

Postby Andy » Tue Oct 26, 2010 11:46 am

russf wrote: The fact that you "can't see how XMOS could ensure the quality of such an offering" ignores the fact that quality is assured trivially by dozens of organizations every day, who maintain mission-critical software, that moves at a much faster pace than XMOS components, all on the basis of open trackers and/or open repositories.
The point about quality was in reference to a 'free-for-all' repository, which was the type of setup I assumed you were proposing from your first post.
russf wrote: Coming to the repository point: I disagree completely. It's a complete waste of time to have a public free-for all repository. This amounts to a fork of the project, and puts an even bigger load on the internal developers. It's very unlikely that either internal or internal developers would find the significant time to merge changes across repositories, and the result would be worse, not better. And yes, XMOS would not be able to ensure quality, simply due to manpower and lack of control. There is a level of effort and discipline to managing a repository. My model has XMOS providing this effort, in return for engaging the help of its customers in improving their product.
I'm not sure you've made it clear exactly what you want. XMOS probably have an internal repository for managing their source - do you propose they make this public?
User avatar
russf
XCore Addict
Posts: 146
Joined: Thu Dec 10, 2009 10:17 pm

Postby russf » Tue Oct 26, 2010 3:32 pm

Hi @Jason, thanks for your comments....
jason wrote:Hi Russ,

- What is stopping the community from taking the existing code, making a GitHub repository, and then maintaining and developing that in to something amazing?
Nothing at all!

But there are some problems. I am assuming that XMOS would continue to push out occasional updates.
  • Unofficial releases start to compete with official ones. They tend to undermine each other and split the user-base. Because the efforts of the XMOS and external teams are likely to be divided, the quality of the code in both is likely to be lower than if both worked on a shared repository.

    Both repositories require upkeep, so there is duplication of effort.

    The coders around the external repository would meet (virtually?) and advance the product. XMOS might drift outside that discussion, and this is contrary to the goals of all (see below).
However, if XMOS made a clear statement that there is no intention of maintaining, let's say XTCP, the users could come together around an external repository, fix it, extend it, etc. It is the fear that XMOS might throw a new, fixed up version over the wall that prevents an external repository from emerging and thriving.

Merging fixes from diverged repositories is a stupid, time-consuming, and error-prone task, that should be avoided.
jason wrote: If you were to start at XMOS tomorrow in charge of taking on this project, what would you do? How would you satisfy customers who do not want to use OpenSource code (they do exist) - do we then have 2 versions? One open source, one closed? If that is the case, how is that different to my first point?

Apologies if I have missed the point, please do point me in the right direction.

All the best,

Jason
If I started at XMOS tomorrow, I would first validate that the commercial goals of the company are to sell IP related to silicon, and to facilitate those sales by making early release of modules of high quality free code that demonstrate the hardware capabilities, and seed the growth of high-turnover businesses.

I would open discussions about quality and community engagement. I would drive home the message that untested code is broken code; that well crafted tests should be delivered as part of each delivered module, and be seen as an integral and first-class part of that module. I would recommend that a test scenario be documented for all tests requiring hardware (I'm thinking of XTCP testing, running on the XC-2, with a host for communications, for example). I would encourage a philosophy of test-driven development and reward employees who learn to wield that magic sword.

Then I would open discussions with the internal and external communities to determine how they would prefer to work. Which repository (git, or svn for example) would best support internal and external projects, for example. I would engage with the community to determine who would be interested in submitting patches, testing early fixes, and bring them into a mailing list.

I would open another discussion with the community about maintaining rights to contributed code, and form a foundation, run as a non-profit organization, and with representation from XMOS and customers. I would give that foundation a *small* budget for one year, to help get it established, and cover legal and accounting costs. There need only be a handful of members initially, but the foundation would grow, and become self-funded. The board would meet weekly, attendance would be recorded, and reported to the membership. Beyond the initial funding, the foundation would be independent. A key task of the foundation would be to choose a license for the code in the repository. In general I would recommend a license that encouraged contributions, but allowed integration with closed source code without forcing that code to be published. In other words, a very commercially-friendly license. Several such licences are well established, and I would recommend adopting one without customization. The initial charter of the foundation would seat an initial board, whose primary goal would be to setup elections of the membership after 6 months, and then hand control to the incoming elected board.

Over a period of one or two months, I would task XMOS developers to take existing released code and place in one or more repositories. We would draft and publish some guidelines about how those repositories will be used. We would give universal read access. I would encourage external contributors to apply for write access after signing a document assigning their rights to contributed code to the foundation mentioned above. The goal here is to place all code in the repositories in a legal position where neither XMOS nor other contributors could re-assert ownership over code that might by now be incorporated in your latest product. The contributor agreement would also address the need to keep the codebase clean and clear of sections that are subject to third-party copyright.

I would start a new public ticketing system and move across as many existing tickets as possible. New tickets could be tagged private, to address security related issues, or cases where customers need to reveal proprietary information.

I would hold (sponsor) regular meetings of staff and customers, as peers, to work on areas that require improvement. Quarterly would be a starting point. I would encourage bigger customers to take over sponsorship of such events.

Concrete example: I would invite people who have expressed interest in using the current TCP/IP stack for the XC-2 to a space in Bristol that's equipped with WiFi, coffee, and soft drinks. The meeting would last three days, and probably be tagged onto the beginning or end of some related event. Before the meeting we would talk about what we want to achieve, get up to speed on what the options are, and perhaps write some clean test modules that should both document and exercise the stack from above. These test modules might not function at this stage, but they should demonstrate what is expected. This is test-drive development, after all. During the meeting I would suggest that we all start from where we are... some may not be familiar with all the tools, repositories, etc. others may not be familiar with the architecture. On the first day, I would encourage those who wrote the respective layers to give brief informal talks about what they have done. There should be a brief talk about repositories, and there should be an opportunity to get development tools up to a common basis. This should not be a confrontational environment ;) Groups may naturally form to work on specific aspects. Pair programming should be encouraged, with frequent changes of partner. There may be a couple of experimenters who want to expose or develop a new feature. Twice daily status summaries would help maintain focus, and cohesion. The initial outcome of this meeting may need further polishing, but the goal would be to improve or extend existing code, then make a release acknowledged as an outcome of that meeting. (In this concrete case, I would be hoping for sustained reliable data rate of 10Mbit/sec in or out, and better test-coverage. But other members of the group would also bring their own goals.)

I would encourage independent developers, corporate customers, and internal staff to come together in such meetings (I'd call them sprints, based on established practice elsewhere). I would slice out a piece of the marketing budget to sponsor the meetings where appropriate.

I would encourage (sponsor?) an annual meeting of this new movement, varying the location to stimulate interest and recognize the diversity of the members. The meeting would have many opportunities for deep social as well as technical and business engagement.

Regarding customers who do not want to use Open Source code: I would determine the rationale for that stance. Perceptions of quality? Licensing? Whatever? I would explain that there is every reason that Open Source code should develop faster and be cleaner than closed source, and address any unfounded fears or prejudice. If the issue is proprietary algorithms, IP, then we are talking about code that should be kept in a custom repository. In that case there is no need for duplication. Can you tell me what these customers are we trying to address here?

Finally, I would engage with and attempt to address the needs of groups interested in algorithms, devices, standards, etc. I would visit commercial and University groups developing new devices, protocols, etc. I would use my existing mailing list to bring customers together around new and shared projects. I would attempt to bring the authors of important device-driver stacks and others interested in their own components into the fold. I would encourage component developers to sponsor foundation members to develop drivers for them.

The vision is that XMOS and the user community would benefit from and support each other. Together we would develop an eco-system that's successful for all concerned.

For many of the "I"s above, I would substitute "We" as soon as possible. It would be important to foster a culture of shared responsibility for community engagement across the whole of XMOS. At that point, we would as a company be able to do more asking than telling and more shipping than selling.

OK. Jason. Do I get the job? Or do you? ;)
User avatar
russf
XCore Addict
Posts: 146
Joined: Thu Dec 10, 2009 10:17 pm

Postby russf » Tue Oct 26, 2010 3:44 pm

Andy wrote:
russf wrote: The fact that you "can't see how XMOS could ensure the quality of such an offering" ignores the fact that quality is assured trivially by dozens of organizations every day, who maintain mission-critical software, that moves at a much faster pace than XMOS components, all on the basis of open trackers and/or open repositories.
The point about quality was in reference to a 'free-for-all' repository, which was the type of setup I assumed you were proposing from your first post.
russf wrote: Coming to the repository point: I disagree completely. It's a complete waste of time to have a public free-for all repository. This amounts to a fork of the project, and puts an even bigger load on the internal developers. It's very unlikely that either internal or internal developers would find the significant time to merge changes across repositories, and the result would be worse, not better. And yes, XMOS would not be able to ensure quality, simply due to manpower and lack of control. There is a level of effort and discipline to managing a repository. My model has XMOS providing this effort, in return for engaging the help of its customers in improving their product.
I'm not sure you've made it clear exactly what you want. XMOS probably have an internal repository for managing their source - do you propose they make this public?
Regarding free-for-all repositories. Such things do exist, but work best where at least someone can take out the trash. I had in mind a repository that's managed by XMOS, but allows contributions from outside, and has a trunk that is aggressively maintained, with, ideally, full test coverage and some discipline. Releases should be made on that trunk at intervals. Many customers would take those tested releases, and not work off HEAD unless they wanted the bleeding-edge with latest bug-fixes.

And yes. I was suggesting that XMOS move a substantial body of code into a public repository, but with control of contributions and contributors. Even non-committers could contribute diffs to committers for consideration. This would widen the scope for having fixes applied quickly and efficiently. With the current state of affairs I can't even tell if my bugs are already ticketed, and fixed, awaiting release. That's demoralizing.

Yes. There are ways that opening the repository could go wrong. This should be avoided. It just requires discussion.
Last edited by russf on Wed Oct 27, 2010 2:18 am, edited 1 time in total.
Reason: fixed tiny typo, punctuation. Smoothed a sentence.
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm

Postby Folknology » Tue Oct 26, 2010 9:32 pm

- What is stopping the community from taking the existing code, making a GitHub repository, and then maintaining and developing that in to something amazing?
I think this is the likely route for many if Xmos do not follow Russ's and others suggestions for open (github like) repositories. In many cases, those taking this route won't bother to try to merge back to Xmos releases for obvious reasons i.e. lack of openness and commitment to open development along with shear amount of work involved in such discontinuous merges. Instead what tends to happen in these situations is that the code will fork and fragment, moving away from Xmos mainline. This would likely be a loss for Xmos unless this is a planned/desired effect, my guess is that this would not be what Xmos would prefer strategically, moving forward. If a community is well fostered Xmos will likely yield its dividends with the community itself, diverse forking against Xmos mainline will in effect result in lost dividends to Xmos, also if this behaviour is continued to its natural conclusion it would result in loss of authority and or credentials which could be devastating for Xmos from a community perspective.
The point about quality was in reference to a 'free-for-all' repository, which was the type of setup I assumed you were proposing from your first post.
I am not aware of successful opensource projects that operate "free-for-all" repositories, the mainline trunks are operated by committed teams that deliver greatest value on the projects, such privilege is acquired via good work, kudos and karma. Such systems are less formal but result in self governance, much has been written about and analysed around such opensource projects it may be worth taking a look at what's out there in this field. It also worth reiterating Russ in that many have already trod this path successfully in both commercial and non-commercial organisations, this isn't really anything new, its been around for the last decade or so.
I'm not sure you've made it clear exactly what you want. XMOS probably have an internal repository for managing their source - do you propose they make this public?
As far as internal vs external, obviously the most valuable from a community POV is make it public i.e. external. This is also where something like GIT as a version control system offers advantages. Because git is a distributed version control system it enables very powerful concurrent and distributed development. and makes it much simpler when it comes to the time you need to make disparate merges.I personally find this feature very useful when using opensource code with commercial forks. often the commercial forks are not forks in the true sense, they often just contain small or custom changes suitable for the commercial project (mainly sensitive data and settings). Merging the upstream changes back into the minor forks is trivial and as such these can track the mainline despite having custom tweaks. Perhaps this approach could be helpful for Xmos. In fact github for example allows you to create commercial/private accounts which allow you to create both public and private projects which is exactly how I operate with various opensource and commercial codebases that I rely on.


Just my $0.02

regards
Al
User avatar
Interactive_Matter
XCore Addict
Posts: 216
Joined: Wed Feb 10, 2010 10:26 am

Postby Interactive_Matter » Wed Oct 27, 2010 11:05 am

I have to agree to Folknology and rusff.

By going open source you will not loose any bit of control and gain support and bug fixes from the community.
XMOS and trusted community members will be the committers and ensure quality and stability of the platform.

To address the concenrs of stability and quality: There will be different branches - e.g. as you find in other open source projects as well:
- There will be a lot of spin offs and private repositories -they change things, fix bugs and probably eventually die if the maintainer looses interest. but they will contribute improvements and bug fixes. Since it is easier and more stable to use the official XMOS branches most people will concentrate on this.
- There will be a quite fast moving HEAD, which incorporates bug fixes and approved patches , e.g. to implement new features. This is the place the community contributes too.
- There will be stable relases, which evolve by incorporating bug fixes. They are API stable and enable customers to use them for years. The price of the stability: You do not get new features, just bug fixes.

I do not think that the maintenance costs for XMOS are much bigger than they are now. But the momentum in each library will be much bigger than now. Since if I understand it correctly. Folknology wants eagerly to contribute to the x_tcp library. What is the business value of keeping him out of the game?

From my point of view XMOS is quite open. And now it has to live with the consequence: The community wants it to go the whole way. And from my point of view it is the best way to go.

By that you will create a vivid ecosystem adding more and more functionality to XMOS devices - and by that you will simply sell more chips.

Or to put it the other way around: Why should I choose to use an ARM competitor? Since there I got (more or less, depending on the specific hardware) the complete Linux stack which provides a lot of usefull software for me. So I only have to conentrate on the specifixc problem I want to solve. The libraries for the commodity functionality is there (Kernel, networking, device drivers, web server and so on). This comparison is a bit weak, but I hope it illustrates my point.

Who is online

Users browsing this forum: No registered users and 1 guest