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? ;)