Acting (and coding) your age

With seniority comes perks, but it also comes with responsibilities.

I dropped a post on LinkedIn a few days ago:

I’m now 50 years old and writing the most complex code in my career (for Enarx) in a language (Rust) that I only started learning 9 months ago and I’ve just finished the first draft of a book (for Wiley). Not sure what’s going on (and I wouldn’t have believed you if you’d told me this 25 years ago). #codingtips #writing #security #confidentialcomputing #rustlang

I’ve never received such attention. Lots of comments, lots of “likes” and other reactions, lots of people wanting to connect. It was supposed to be a throw-away comment, and I certainly had no intention either to boast or elicit sympathy: I am genuinely surprised by all of the facts mentioned – including my age, given that I feel that I’m somewhere between 23 and 31 (both primes, of course).

I remember in my mid- to late-twenties thinking “this business stuff is pretty simple: why don’t the oldies move aside and let talented youngsters[1] take over, or at least provide them some inspired advice?” Even at the time I realised that this was a little naive, and that there is something to be said for breadth of experience and decades of acquired knowledge, but I’m pretty certain that this set of questions has been asked by pretty much every generation since Ogg looked at the failings in his elders’ flint spear-head knapping technique and later got into a huff when his mum wouldn’t let him lead the mammoth hunt that afternoon.

Why expertise matters

Sadly (for young people), there really are benefits associated with praxis (actually doing things), even if you’ve absorbed all of the theory (and you haven’t, which is one of the things you learn with age). Of course, there’s also the Dunning-Kruger effect, which is a cognitive bias (Trust you? I can’t trust myself.) which leads the inexperienced to overestimate their own ability and experts to underestimate theirs.

Given this, there are some interesting and bizarre myths around about software/coding being a “young man’s game”. Leaving aside the glaring gender bias in that statement[2], this is rather odd. I know some extremely talented over-40 and over-50 software engineers, and I’m sure that you can think of quite a few if you try. There are probably a few factors at play here:

  • the lionisation of the “start-ups in the garage” young (mainly white) coders turning their company into “unicorn” trope;
  • the (over-)association of programming with mathematical ability, where a certain set of mathematicians are considered to have done their best work in their twenties;
  • the relative scarcity of roles (particularly in organisations which aren’t tech-specific) of “individual contributor” career tracks with roles where it’s possible to rise in seniority (and pay) without managing other people;
  • a possible tendency (which I’m positing without much evidence) for a sizeable proportion of senior software folks to take a broader view of the discipline and to move into architectural roles which are required by the industry but are difficult to perform without a good grounding in engineering basics.

In my case, I moved away from writing software maybe 15 years ago, and honestly never thought I’d do any serious coding again, only to discover a gap in the project I’m working on (Enarx) which nobody else had the time to fill, but which I felt merited some attention. That, and a continuous desire to learn new things, which had led me to starting to learn Rust, brought me to some serious programming, which I’ve really enjoyed.

We need old coders: people who have been around the block a few times, have made the mistakes and learned from them. People who can look at competing technologies and make reasoned decisions about which is the best fit for a project, rather than just choosing the newest and “coolest”[3].

Why old people should step aside

Having got all of the above out of my system, I’m now going to put forward an extremely important counter-argument. First, some context. I volunteer for the East of England Ambulance Service Trust as a Community First Responder, a role where I attend patients in (possible) emergency situations and work with ambulance staff, paramedics, etc.. I’ve become very interested in some of the theory around patient safety, which it turns out is currently being strongly influenced by lessons learned over the past few decades from transport safety, particularly aviation safety[5].

I need to do more study around this topic, as there are some really interesting lessons that can be applied to our sector (in fact, some are already be learned from our sector, particularly in how DevOps/WebOps respond to incidents), but there are two points that have really hit home for me this week, and which are relevant to the point at hand. They are specifically discussed with relation to high-intensity, stressful situations, but I think there’s broader applicability.

1. With experience comes expectation

While experience is enormously useful – bringing insights and knowledge that others may not have, or will find difficult to synthesise – it can also lead you down paths which are incorrect. If you’ve seen the same thing 99 times, you’re likely to assume that the 100th will be the same: bringing in other voices, including less experienced ones, allows other views to be considered, giving a better chance that the correct conclusion will be met. You increase diversity of opinion and allow alternatives to be brought into the mix. The less experience team members may be wrong, but from time to time, you’ll be wrong, and everyone will benefit from this. By allowing other people a voice, you’re also setting an example that speaking up and offering alternative views is not only acceptable, but valued. You and the team get to learn from each other, whether it’s when you’re wrong, or when you’re right, but you get to discuss with others how you came to your conclusions, and welcome their probing and questions around how you got there.

2. Sometimes you need to step aside to apply yourself elsewhere

Perhaps equally important is that sometimes, tempting as it may be to get your hands dirty and apply your expertise to a particular problem (particularly one which is possibly trivial to you), there are times when it’s best to step aside and let someone less experienced than you do it. Not only because they need the experience themselves, but also because your skills may be better applied at a systems level or dealing with other problems in other contexts (such as funding or resource management). The example sometimes given in healthcare is when a senior clinician arrives on scene at an incident: rather than their taking over the treatment of patients (however skilled the senior clinician may be), their role is to see the larger situation, to prioritise patients for treatment, assess risks to staff on scene, manage transport and the rest. Sometimes they may need to knuckle down and apply their clinical skills directly (much as senior techies may end up coding to meet a demo deadline, for instance), but most of the time, they are best deployed in stepping aside.

Conclusion

With seniority comes perks: getting to do the interesting stuff, taking decisions, having junior folks make the tea and bring the doughnuts in[6]. But it also comes with responsibilities: helping other people learn, seeing the bigger picture, giving less experienced team members the chance to make mistakes, removing barriers imposed by organisational hierarchy and getting the first round in at the pub[7]. Look back at what you were thinking about the beginning of your career, and give your successors (because they will be your successors) the chances that you were so keen for back then. Show them respect, and you (and your organisation) will benefit.


1 – I think that the “like me” is pretty implicit here, yes?

2 – which, sadly, reflects another bias in the market.

3 – there’s an important point here: many of us older folks love new shiny things just as much as the youngsters, and are aware of the problems of the old approaches and languages – but we’re also aware that there are risks and pain points associated with the new, which need to be taken into account[4].

4 – that really made me sound old, didn’t it?

5 – in large part influenced by the work of Martin Bromiley, a civil aviation pilot whose wife Elaine died in a “routine” operation in 2005 and who has worked (and is working) to help the health care sector transition to a no-blame, “just” culture around patient safety.

6 – this is a joke: if you have ever, ever find yourself in an office or team where this is the norm, and hierarchy shows in this sort of way, either get out or change that culture just as soon as you can. It’s toxic.

7 – I’m writing this in the middle of the UK’s second Covid-19 lockdown, and can barely remember what a “pub” or a “round” even is.

The importance of process (and people and rules)

If there is no process, you can throw technology at it as much as you want, but you are still likely to fail.

Those of us in Europe awoke to the news that the US electoral college have voted for Joe Biden as 46th President of the United States of America. Getting to this point has seemed (at least from the outside) to be a rather tortuous route, but from my understanding of how the US Constitution works[1], this is it: the process is complete and Joe Biden will be sworn in a President of the United States on a (probably very chilly) day next month, at the beginning of 2021. I have no intention of weighing the pros and cons of the candidates, nor even of examining the process (sometime labelled “arcane” by journalists”) by which US presidents are elected, but I do want to spend some time on the fact that there is a process, and thinking about how that works, and what supports it.

This is, first and foremost, a blog about IT security (though I have been known to post on a much wider range of issues from time to time), and so I unsurprisingly spend quite a lot of time discussing technology, but on this occasion I want to avoid doing that, as far as possible. If we look at the process for electing a US president, one of the most striking things about it, we might note, is the lack of technology. Yes, there are electronic voting machines to allow votes to be cast, yes, a myriad computers are deployed by psephologists[2] to forecast the results, but the actual process is lacking in much that we would normally think of as technology.

We often fixate on technology, but if there is no process in place to get from point A to point B, then you can throw technology at it as much as you want, but you are still likely to fail. Those points may be getting from having no president-elect to having a new president, completing a transaction to buy a house or a paperclip, hiring a new CEO or sous-chef, moving from a set of requirements to a working software program, or literally getting from a point A on a map to point B – they all require a process.

What is a process? Google, courtesy of Oxford Languages, offers the definition: a series of actions or steps taken in order to achieve a particular end. This seems like a useful description, but in the contexts we’re describing, it is the fact that the actions or steps are defined which is important. In the world of computing, we might say that there is an algorithm to be followed to complete the process. This algorithm allows a variety of things, all of which are important:

  1. the writing down and codification of the process;
  2. the allocation of different people to different roles in the process;
  3. norms, rules, regulation and/or legislation to be created to ensure the correct following of the process;
  4. the application of technology to simplify, speed up or automate parts of the process.

I don’t want to talk about point 4 particularly – I spend far too much of my time on that in most of my life – and the ways of achieving point 1 are so diverse as to defy consideration in this context, so let’s briefly discuss points 2 and 3.

Allocating people

If you have a process, you can break that process into steps, you can assign roles and responsibilities to those steps. This is useful in a variety of ways, the first of which is that you can start to scale the process by having different people working on different steps – sometimes in parallel. Imagine having one person having to count all of the votes in the US presidential election, or even having multiple people doing it, but having to do so in series: it might work, but it’s going to take way too long. Another benefit is one on which the Industrial Revolution was built: specialisation. Some people will be good at some parts of the process, and others at other parts of the process. You can increase efficiency by putting those with expertise on the right pieces of the process. A third, unrelated to efficiency, is separation of responsibilities. Sometimes, it’s important that certain people, who are experts or certified to perform a particular role, are the ones who do that. Often, it’s even more important that certain people don’t perform those roles. An example of this would be if one of the candidates in an election was the one to perform the final tally of votes and hand the result to the person making the announcement, or if they made the announcement themselves. This is equally true for other types of process: your bank does not want you to be the person who provides the final approval for your loan, and a company does not want a spouse, partner or family member to be providing sign-off for a hiring decision.

Norms, rules, regulation and legislation

In the UK, we have strong social norms around the process of queuing, and you will be subject to social (and sometimes stronger!) censure if you break them. Rules around other processes may be stronger, and sometimes regulation by an industry body or even legislation at the nation level (or multi-national level such as EU or UN) is required to safeguard the appropriate execution of a process. The ability for courts to intervene where vote-rigging may have taken place is a good example in the US election process, but legislation and regulation around anything from wiring a house to what fertilisers are allowed on particular crops provide additional levels of checking and assurance that processes are following correctly (by including censure or punishment for those who have contravened them) or can be remedied when not (through other processes such as legal review or court cases).

Legislation and regulation can be annoying, but without them (or equivalent rules and norms for other types of process), we cannot be sure of what we are getting into, or whether, if we get into it improperly, that we will ever get out of it. People support and are subject to these checks and balances, and without the combination of all of them (not forgetting the technology as well), processes are next to useless.


1 – I am not a lawyer. Nor a constitutional expert. Nor even a US citizen. Basically, do not take my word for any of this.

2 – I love this word. We should use it more often.

How open source builds distributed trust

Trust in open source is a positive feedback loop

This is an edited excerpt from my forthcoming book on Trust in Computing and the Cloud for Wiley, and leads on from a previous article I wrote called Trust & choosing open source.

In that article, I asked the question: what are we doing when we say “I trust open source software”? In reply, I suggested that what we are doing is making a determination that enough of the people who have written and tested it have similar requirements to mine, and that their expertise, combined, is such that the risk to my using the software is acceptable. I also introduced the idea of distributed trust.

The concept of distributing trust across a community is an application of the theory of the wisdom of the crowd, posited by Aristotle, where the assumption is that the opinions of many typically show more wisdom than the opinion of one, or a few. While demonstrably false in its simplest form in some situations – the most obvious example being examples of popular support for totalitarian regimes – this principle can provide a very effective mechanism for establishing certain information.

This distillation of collective experience allows what we refer as distributed trust, and is collected through numerous mechanisms on the Internet. Some, like TripAdvisor or Glassdoor, record information about organisations or the services they provide, while others, like UrbanSitter or LinkedIn, allow users to add information about specific people (see, for instance, LinkedIn’s “Recommendations” and “Skills & Endorsements” sections in individual’s profiles). The benefits that can accrue from of these examples are significantly increased by the network effect, as the number of possible connections between members increases exponentially as the number of members increases. Other examples of distributed trust include platforms like Twitter, where the number of followers that an account receives can be seen as a measure of their reputation, and even of their trustworthiness, a calculation which we should view with a strong degree of scepticism: indeed, the company Twitter felt that it had to address the social power of accounts with large numbers of followers and instituted a “verified accounts” mechanism to let people know “that an account of public interest is authentic”. Interestingly, the company had to suspend the service after problems related to users’ expectations of exactly what “verified” meant or implied: a classic case of differing understandings of context between different groups.

Where is the relevance to open source, then? The community aspect of open source is actually a driver towards building distributed trust. This is because once you become a part of the community around an open source project, you assume one or more of the roles that you start trusting once you say that you “trust” an open source project (see my previous article): examples include: architect, designer, developer, reviewer, technical writer, tester, deployer, bug reporter or bug fixer. The more involvement you have in a project, the more one becomes part of the community, which can, in time, become a community of practice. Jean Lave and Etienne Wenger introduced the concept of communities of practice in their book Situated Learning: Legitimate Peripheral Participation, where groups evolve into communities as their members share a passion and participate in shared activities, leading to their improving their skills and knowledge together. The core concept here is that as participants learn around a community of practice, they become members of it at the same time:

“Legitimate peripheral participation refers both to the development of knowledgeably skilled identities in practice and to the reproduction and transformation of communities of practice.”

Wenger further explored the concept of communities of practice, how they form, requirements for their health and how they encourage learning in Communities of Practice: Learning, meaning and identity. He identified negotiability of meaning (“why are we working together, what are we trying to achieve?”) as core to a community of practice, and noted that without engagement, imagination and alignment by individuals, communities of practice will not be robust.

We can align this with our views of how distributed trust is established and built: when you realise that your impact on open source can be equal to that of others, the distributed trust relationships that you hold to members of a community become less transitive (second- or third-hand or even more remote), and more immediate. You understand that the impact that you can have on the creation, maintenance, requirements and quality of the software which you are running can be the same as all of those other, previously anonymous contributors with whom you are now forming a community of practice, or whose existing community of practice you are joining. Then you yourself become part of a network of trust relationships which are distributed, but at less of a remove to that which you experience when buying and operating proprietary software. The process does not stop there, however: a common property of open source projects is cross-pollination, where developers from one project also work on others. This increases as the network effect of multiple open source projects allow reuse and dependencies on other projects to rise, and greater take-up across the entire set of projects.

It is easy to see why many open source contributors become open source enthusiasts or evangelists not just for a single project, but for open source as a whole. In fact, work by Mark Granovetter suggests that too many strong ties within communities can lead to cliques and stagnation, but weak ties provide for movement of ideas and trends around communities. This awareness of other projects and the communities that exist around them, and the flexibility of ideas across projects, leads to distributed trust being able to be extended (albeit with weaker assurances) beyond the direct or short-chain indirect relationships that contributors experience within projects of which they have immediate experience and out towards other projects where external observation or peripheral involvement shows that similar relationships exist between contributors. Put simply, the act of being involved in an open source project and building trust relationships through participation leads to stronger distributed trust towards similar open source projects, or just to other projects which are similarly open source.

What does this mean for each of us? It means that the more we get involved in open source, the more trust we can have in open source, as there will be a corresponding growth in the involvement – and therefore trust – of other people in open source. Trust in open source isn’t just a network effect: it’s a positive feedback loop!

Do I trust this package?

The area of software supply chain management is growing in importance.

This isn’t one of those police dramas where a suspect parcel arrives at the precinct and someone realises just in time that it may be a bomb – what we’re talking about here is open source software packages (though the impact on your application may be similar if you’re not sufficiently suspicious). Open source software is everywhere these days – which is great – but how can you be sure that you should trust the software you’ve downloaded to do what you want? The area of software supply chain management – of which this discussion forms a part – is fairly newly visible in the industry, but is growing in importance. We’re going to consider a particular example.

There’s a huge conversation to be had here about what trust means (see my article “What is trust?” as a starting point, and I have a forthcoming book on Trust in Computing and the Cloud for Wiley), but let’s assume that you have a need for a library which provides some cryptographic protocol implementation. What do you need to know, and what are you choices? We’ll assume, for now, that you’ve already made what is almost certainly the right choice, and gone with an open source implementation (see many of my articles on this blog for why open source is just best for security), and that you don’t want to be building everything from source all the time: you need something stable and maintained. What should be your source of a new package?

Option 1 – use a vendor

There are many vendors out there now who provide open source software through a variety of mechanisms – typically subscription. Red Hat, my employer (see standard disclosure) is one of them. In this case, the vendor will typically stand behind the fitness for use of a particular package, provide patches, etc.. This is your easiest and best choice in many cases. There may be times, however, when you want to use a package which is not provided by a vendor, or not packaged by your vendor of choice: what do you do then? Equally, what decisions do vendors need to make about how to trust a package?

Option 2 – delve deeper

This is where things get complex. So complex, in fact, that I’m going to be examining them at some length in my book. For the purposes of this article, though, I’ll try to be brief. We’ll start with the assumption that there is a single maintainer of the package, and multiple contributors. The contributors provide code (and tests and documentation, etc.) to the project, and the maintainer provides builds – binaries/libraries – for you to consume, rather than your taking the source code and compiling it yourself (which is actually what a vendor is likely to do, though they still need to consider most of the points below). This is a library to provide cryptographic capabilities, so it’s fairly safe to assume that we care about its security. There are at least five specific areas which we need to consider in detail, all of them relying on the maintainer to a large degree (I’ve used the example of security here, though very similar considerations exist for almost any package): let’s look at the issues.

  1. build – how is the package that you are consuming created? Is the build process performed on a “clean” (that is, non-compromised) machine, with the appropriate compilers and libraries (there’s a turtles problem here!)? If the binary is created with untrusted tools, then how can we trust it at all, so what measures does the maintainer take to ensure the “cleanness” of the build environment? It would be great if the build process is documented as a repeatable build, so that those who want to check it can do so.
  2. integrity – this is related to build, in that we want to be sure that the source code inputs to the build process – the code coming, for instance, from a git repository – are what we expect. If, somehow, compromised code is injected into the build process, then we are in a very bad position. We want to know exactly which version of the source code is being used as the basis for the package we are consuming so that we can track features – and bugs. As above, having a repeatable build is a great bonus here.
  3. responsiveness – this is a measure of how responsive – or not – the maintainer is to changes. Generally, we want stable features, tied to known versions, but a quick response to bug and (in particular) security patches. If the maintainer doesn’t accept patches in a timely manner, then we need to worry about the security of our package. We should also be asking questions like, “is there a well-defined security disclosure of vulnerability management process?” (See my article Security disclosure or vulnerability management?), and, if so, “is it followed”?
  4. provenance – all code is not created equal, and one of the things of which a maintainer should be keeping track is the provenance of contributors. If a large amount of code in a part of the package which provides particularly sensitive features is suddenly submitted by an unknown contributor with a pseudonymous email address and no history of contributions of security functionality, this should raise alarm bells. On the other hand, if there is a group of contributors employed by a company with a history of open source contributions and well-reviewed code who submit a large patch, this is probably less troublesome. This is a difficult issue to manage, and there are typically no definite “OK” or “no-go” signs, but the maintainer’s awareness and management of contributors and their contributions is an important point to consider.
  5. expertise – this is the most tricky. You may have a maintainer who is excellent at managing all of the points above, but is just not an expert in certain aspects of the functionality of the contributed code. As a consumer of the package, however, I need to be sure that it is fit for purpose, and that may include, in the case of the security-related package we’re considering, being assured that the correct cryptographic primitives are used, that bounds-checking is enforced on byte streams, that proper key lengths are used or that constant time implementations are provided for particular primitives. This is very, very hard, and the job of maintainer can easily become a full-time one if they are acting as the expert for a large and/or complex project. Indeed, best practice in such cases is to have a team of trusted, experienced experts who work either as co-maintainers or as a senior advisory group for the project. Alternatively, having external people or organisations (such as industry bodies) perform audits of the project at critical junctures – when a major release is due, or when an important vulnerability is patched, for instance – allows the maintainer to share this responsibility. It’s important to note that the project does not become magically “secure” just because it’s open source (see Disbelieving the many eyes hypothesis), but that the community, when it comes together, can significantly improve the assurance that consumers of a project can have in the packages which is produces.

Once we consider these areas, we then need to work out how we measure and track each of them. Who is in a position to judge the extent to which any particular maintainer is fulfilling each of the areas? How much can we trust them? These are a set of complex issues, and one about which much more needs to be written, but I am passionate about exposing the importance of explicit trust in computing, particularly in open source. There is work going on around open source supply chain management, for instance the new (at time of writing Project Rekor – but there is lots of work still to be done.

Remember, though: when you take a package – whether library or executable – please consider what you’re consuming, what about it you can trust, and on what assurances that trust is founded.

15 steps to prepare for (another) lockdown

What steps can we be taking to prepare for what seems likely now – a new lockdown?

The kids are back in school, there are people in shops and restaurants, and traffic is even beginning to get back to something like normal levels. I’m being deployed as a CFR (community first responder) to more incidents, as the ambulance service gets better at assessing the risks to me and patients. And the colds and sneezes are back.

Of course they are: it’s that time of year. And where are they spreading from? Where do they usually spread from? School pupils. Both of mine have picked up minor cold symptoms, but, luckily nothing suggesting Covid-19. The school they attend is following government advice by strongly recommending that pupils wear masks in communal areas, encouraging social distancing and providing hand sanitiser outside each classroom, to be used on entry. Great! That should limit Covid-19. And it should… but the sore throats, coughing and sneezing started within days of their return to school. I’m no expert but it seems likely (and many experts agree) that schools will be act as transmission vectors, and that the rates of infection of Covid-19 will start rising again. And yes, the UK already has an R figure well above 1.

Apart from ranting about how this was always likely to happen, and that the relevant authorities should have taken more steps to reduce the impact) both true), what steps can we be taking to prepare for what seems likely now – a new lockdown?

Physical steps

There are a number of things that I’ve done or plan to do to prepare. Some of them aren’t because I necessarily expect a full lockdown, but some because, if I feel ill and unable to leave the house, it’s best to be ready.

  • get provisions – what do we need in for food and drink? We should obviously not go overboard on alcohol, but if you like a glass of wine from time to time, get a few bottles in, maybe a nice one for a special occasion. Get dried food in, cooking oil, and the rest stock the freezer. Oh, and chocolate. Always chocolate.
  • household supplies – remember that run on random items at the beginning of the first lockdown? Let’s avoid that this time: get toilet paper, kitchen roll, cleaning materials and tissues (for when we feel really poorly).
  • work supplies – most of us are used to working at home now, but if you’ve got a dodgy monitor, a printer in need of paper, or a webcam that’s on its last legs, now is a good time to sort them out there’s a good chance that these might become difficult to get hold of (again).
  • fitness preparations – if the gyms close again, what will you do? Even if we’re allowed outside more for exercise this time round, those warm jogging shorts that you wore in the spring and summer are not what you want to be wearing in the sleet and snow, so buy whatever gear you need for indoor or outdoor use now.
  • get a haircut – or get hold of some hairdressing supplies. Many of us discovered that we or our family members had some skills in this department, but better to get a cut in preparation, right?
  • books – yes, there are alternatives to physical books: you can read on your phone or another device these days. But I like a physical book, and I wish I’d stocked up last time. Go to your friendly neighbourhood book store – they need your business right now – and buy a few books.
  • wood – we live in an old house, and have wood-burning stoves to supplement our heating. Get wood in now to avoid getting cold in the winter!
  • pay the bills – you may want or need some extra luxuries later, as the weather sets in and lockdown takes hold. Get the bills paid up front, so there are no nasty surprises and you can budget a few treats for yourself later.

Psychological steps

Just as important as the physical – more, probably – is psychological preparation. That doesn’t mean that the steps above aren’t important: in fact, they’re vital to allow you to have space to consider the psychological preparation, which is difficult if you’re concerned or unsure about your physical safety and environment.

Prioritise – if you can, work out now what you’re going to prioritise, and when. Sometimes work may come first (barring an emergency), sometimes family, sometimes you. Thinking about this now is a good plan, so that you can set some rules for yourself and for those around you.

Prepare your family – this isn’t just about the priorities you’ve already worked on in the previous point, but also more generally. Many of us struggled with lockdown, and although we might think that it’ll be easier second time round, the very fact that it’s happened again is likely to cause us more stress in some ways.

Sleep – sleep now: bank it while you can! Sleep when lockdown happens, too. This was something which was a surprise to me: how tired I got. Not going out is, it turns out, tiring. This is because stress – which was a clear outcome from the first lockdown, and stress can make you very tired. So sleep when you can, and don’t just try to “power through”.

List what you can control and what you can’t – a classic stressor is feeling overwhelmed with things that we can’t control. And there will definitely be things that we really can’t – how long it takes, which of my friends get sick, issues such as that. But equally, there are things that we can control: when I stop for a cup of tea (or coffee, I suppose), who I call to catch up with on the phone, what I have for supper. In order to reduce stress, list things that you can control, and which you can’t, and try to accept the latter. Doing so won’t remove all stress, but it should help you manage your response to that stress, which can help you reduce it.

Be ready to feel weak – you will feel sad and depressed and ill and fed up from time to time. This is normal, and human, and it does not make you a failure or a bad employee, family member, friend or person. Accept it, and be ready to move on when you can.

Think of others – other people will be struggling, too: your family, friends, colleagues and neighbours. Spare them a thought, and think how you can help, even if it’s just with a quick text, a family videochat or a kind word from time to time. Being nice to people can make you feel good, too – and if you’re lucky, they’ll reciprocate, so everyone wins twice!

Be ready to put yourself first – sometimes, you need to step back and say “enough”. This isn’t always easy, but it’s sometimes necessary. If you begin to realise that things are coming unstuck, and that you’re going to have to disengage, let others around you know if you can. Don’t say “I hope it’s OK if…” or “I was thinking about, would it be OK for me to…”. Instead, let them know your intentions: “I’m going to need 5 minutes to myself”, or “I need to drop from this meeting for a while”. This won’t always be easy, but if you can prepare them, and yourself, for taking a little time, it’s going to be better for everyone in the end: you, because you will recover (if only for a while), and them, because they’ll get a healthier, more efficient and less stressed you.

7 tips for managers of new home workers

You will make mistakes. You are subject to the same stresses and strains.

Many organisations and companies are coming to terms with the changes forced on them by Covid-19 (“the coronavirus”), and working out what it means to them, their employees and their work patterns. For many people who were previously in offices, it means working from home.  I wrote an article a few weeks ago called 9 tips for new home workers, and then realised that it wouldn’t just be new home workers who might be struggling, but also their managers.  If you’re reading this, then you’re probably a manager, working with people who don’t normally work from home – which may include you – so here are some tips for you, too.

1 – Communicate

Does that meeting need to be at 9am?  Do you need to have the meeting today – could it be tomorrow?  As managers, we’re used to being (or at pretending to be) the most important person in our team’s lives during the working day.  For many, that will have changed, and we become a distant second, third or fourth. Family and friends may need help and support, kids may need setting up with schoolwork, or a million other issues may come up which mean that expecting attention at the times that we expect it is just not plausible.  Investigate the best medium (or media) for communicating with each separate member of your team, whether that’s synchronous or asynchronous IM, email, phone, or a daily open video conference call, where anybody can turn up and just be present.  Be aware of your team’s needs – which you just can’t do without communicating with them – and also be aware that those needs may change over the coming weeks.

2 – Flex deadlines

Whether we like it or not, there are things more important than work deadlines at the moment, and although you may find that some people produce work as normal, others will be managing at best only “bursty” periods of work, at abnormal times (for some, the weekend may work best, for others the evenings after the kids have gone to bed).  Be flexible about deadlines, and ask your team what they think they can manage.  This may go up and down over time, and may even increase as people get used to new styles of working.  But adhering to hard deadlines isn’t going to help anybody in the long run – and we need to be ready for the long run.

3 – Gossip

This may seem like an odd one, but gossip is good for human relationships.  When you start a call, set aside some time to chat about what’s going on where the other participants are, in their homes and beyond.  This will help your team feel that you care, but also allow you to become aware of some issues before they arise. A word of caution, however: there may be times when it becomes clear in your discussions that a team-member is struggling.  In this case, you have two options. If the issue seems to be urgent, you may well choose to abandon the call (be sensitive about how you do this if it’s a multi-person call) and to spend time working with the person who is struggling, or signposting them directly to some other help.  If the issue doesn’t seem to be urgent, but threatens to take over the call, then ask the person whether they would be happy to follow up later. In the latter case, you must absolutely do that: once you have recognised an issue, you have a responsibility to help, whether that help comes directly from you or with support from somebody else.  

4 -Accommodate

Frankly, this builds on our other points: you need to be able to accommodate your team’s needs, and to recognise that they may change over time, but will also almost certainly be different from yours.  Whether it’s the setting for meetings, pets and children[1], poor bandwidth, strange work patterns, sudden unavailability or other changes, accommodating your team’s needs will make them more likely to commit to the work they are expected to do, not to mention make them feel valued, and consider you as more of a support than a hindrance to their (often drastically altered) new working lives.

5 – Forgive

Sometimes, your team may do things which feel that they’ve crossed the line – the line in “normal” times.  They may fail to deliver to a previously agreed deadline, turn up for an important meeting appearing dishevelled, or speak out of turn, maybe.  This probably isn’t their normal behaviour (if it is, then you have different challenges), and it’s almost certainly caused by their abnormal circumstances.  You may find that you are more stressed, and more likely to react negatively to failings (or perceived failings). Take a step back. Breathe. Finish the call early, if you have to, but try to understand why the behaviour that upset you did upset you, and then forgive it.  That doesn’t mean that there won’t need to be some quiet discussion later on to address it, but if you go into interactions with the expectation of openness, kindness and forgiveness, then that is likely to be reciprocated: and we all need that. 

6 – Forgive yourself

You will make mistakes.  You are subject to the same stresses and strains as your team, with the added burden of supporting them.  You need to find space for yourself, and to forgive yourself when you do make a mistake. That doesn’t mean abrogating responsibility for things you have done wrong, and neither is it an excuse not to apologise for inappropriate behaviour, but constantly berating yourself will add to your stresses and strains, and is likely to exacerbate the problem, rather than relieve it.  You have a responsibility to look after yourself so that you can look after your team: not beating yourself up about every little thing needs to be part of that.

7 – Prepare

Nobody knows how long we’ll be doing this, but what are you going to do when things start going back to normal?  One thing that will come up is the ability of at least some of your team to continue working from home or remotely.  If they have managed to do so given all the complications and stresses of lockdown, kids and family members under their feet, they will start asking “well, how about doing this the rest of the time?” – and you should be asking exactly the same question.  Some people will want to return to the office, and some will need to – at least for some of the time. But increased flexibility will become a hallmark of the organisations that don’t just survive this crisis, but actually thrive after it. You, as a leader, need to consider what comes next, and how your team can benefit from the lessons that you – collectively – have learned. 

1 – or partners/spouses: I caused something of a stir on a video conference that my wife was on today when I came into her office to light her wood-burning stove!

Your job is unimportant (keep doing it anyway)

Keep going, but do so with a sense of perspective.

I work in IT – like many of the readers of this blog. Also like many of the readers of this blog, I’m now working from home (which is actually normal for me), but with all travel pretty much banned for the foreseeable future (which isn’t). My children’s school is still open (unlike many other governments, the UK has yet to order them closed), but when the time does come for them to be at home, my kids are old enough that they will be able to look after themselves without constant input from me. I work for Red Hat, a global company with resources to support its staff and keep its business running during the time of Covid-19 crisis. In many ways, I’m very lucky.

My wife left the house at 0630 this morning to go into London. She works for a medium-sized charity which provides a variety of types of care for adults and children. Some of the adults for whom they provide services, in particular, are extremely vulnerable – both in terms of their day-to-day lives, but also to the possible effects of serious illness. She is planning the charity’s responses, coordinating with worried staff and working out how they’re going to weather the storm. Charities and organisations like this across the world are working to manage their staff and service users and try to continue provision at levels that will keep their service users safe and alive in a context where it’s likely that the availability of back-up help from other quarters – agency staff, other charities, public or private health services or government departments – will be severely limited in scope, or totally lacking.

In comparison to what my wife is doing, the impact of my job on society seems minimal, and my daily work irrelevant. Many of my readers may be in a similar situation, whether it is spouses, family members or other people in the community who are doing the obviously important – often life-preserving – work, and with us sitting at home, appearing on video conferences, writing documents, cutting code, doing things which don’t seem to have much impact.

I think it’s important, sometimes, to look at what we do with a different eye, and this is one of those times. However, I’m going to continue working, and here are some of the reasons:

  • I expect to continue to bring in a salary, which is going to be difficult for many people in the coming months. I hope to be able to spend some of that salary in local businesses, keeping them afloat or easing their transition back into normality in the future;
  • it’s my turn to keep the household running: my wife has often had to keep things going while I’ve been abroad, and I’m grateful for the opportunity to look after the children, shop for groceries and do more cooking;
  • while I’m not sick, there are going to be ways in which I can help our local community, with food deliveries, checks on elderly neighbours and the like.

Finally, the work that I – and the readers of this blog – do, is, while obviously less important and critical than that of my wife and others on the front line of this crisis, still relevant. My wife spent several hours at work creating an online survey to help work out which of her charity’s staff and volunteers could be deployed to what services. Without the staff who run that service, she would be without that capability. Online banking will continue to be important. Critical national infrastructure like power and water need to be kept going; logistics services for food delivery are vital; messaging and conferencing services will provide important means for communication; gaming, broadcast and online entertainment services will keep those who are in isolation occupied; and, at the very least, we need to keep businesses going so that when things recover, we can get the economy going again. That, and there are going to be lots of charities, businesses and schools who need the services that we provide right now.

So, my message today is: keep going, but do so with a sense of perspective. And be ready to use your skills to help out. Keep safe.

Demonising children (with help from law enforcement)

Let’s just not teach children to read: we’ll definitely be safe then.

Oh, dear: it’s happened again. Ill-informed law enforcement folks are demonising people for getting interested in security. As The Register reports, West Midlands police in the UK have put out a poster aimed at teachers, parents and guardians which advises them to get in touch if they find any of the following on a child’s computer:

  • Tor browser
  • Virtual machines
  • Kali Linux
  • Wifi Pineapple
  • Discord
  • Metasploit

“If you see any of these on their computer, or have a child you think is hacking, please let us know so we can give advice and engage them into positive diversions.”

Leaving aside the grammar of that sentence, let’s have a look at those tools. Actually, first, let’s address the use of the word “hacking”. It’s not the first time that I’ve had a go at misuse of this word, but on the whole, I think that we’ve lost the battle in popular media to allow us to keep the positive use of the term. In this context, however, if I ask a teenager or young person who’s in possession of a few of the above if they’re hacking, they answer will probably be “yes”, which is good. And not because they’re doing dodgy stuff – cracking – but because they’re got into the culture of a community where hacking is still a positive word: it means trying stuff out, messing around and coding. This is a world I – and the vast majority of my colleagues – inhabit and work in on a day-to-day basis.

So – those tools. Tor, as they point out, can be used to access the dark web. More likely, it’s being used by a savvy teenager to hide their access to embarrassing material. VMs can apparently be used to hide OSes such as Kali Linux. Well, yes, but “hide”? And there is a huge number of other, positive and creative uses to which VMs are put every day.

Oh, and Kali Linux is an OS “often used for hacking”. Let’s pull that statement apart. It could mean:

  1. many uses of Kali Linux are for illegal or unethical activities;
  2. many illegal or unethical activities use Kali Linux.

In the same way that you might say “knives are often used for violent attacks”, such phrasing is downright misleading, because you know (and any well-informed law-enforcement officer should know) that 2 is more true than 1.

Next is Wifi Pineapple: this is maybe a little more borderline. Although there are legitimate uses for one of these, I can see that they might raise some eyebrows if you starting going around your local area with one.

Metasploit: well, it’s the tool to get to know if you want to get involved in security. There are so many things you can do with it – like Kali Linux – that are positive, including improving your own security, learning how to protect your systems and adopting good coding practice. If I wanted to get an interested party knowledgeable about how computers really work, how security is so often poor, and how to design better, more secure systems, Metasploit would be the tool I’d point them at.

You may have noticed that I left one out: Discord. Dear, oh dear, oh dear. Discord is, first and foremost, a free gaming chat server. If a child is using Discord, they’re probably playing – wait for it – a computer game.

This poster isn’t just depressing – it’s short-sighted, and misleading. It’s going to get children mislabelled and put upon by people who don’t know better, and assume that information put out by their local police service will be helpful and straightforward. It’s all very well for West Midlands police to state that “[t]he software mentioned is legal and, in the vast majority of cases is used legitimately, giving great benefit to those interested in developing their digital skills”, and that they’re trying to encourage those with parental responsibility to “start up a conversation”, but this is just crass.

I have two children, both around teenage age. I can tell you know that any conversation starting with “what’s that on your computer? It’s a hacking tool! Are you involved in something you shouldn’t be?” is not going to end well, and it’s not going to end well for a number of reasons, including:

  • it makes me look like an idiot, particularly if what I’m reacting to is something completely innocuous like Discord;
  • you’re not treating the young person with any level of respect;
  • it’s a negative starting point of engagement, which means that they’ll go into combative, denial mode;
  • it will make them feel that I suspect them of something, leading them to be more secretive from now on.

And, do you know what? I don’t blame them: if someone said something like that to me, that would be precisely my reaction, too. What’s the alternative suggested in the poster? Oh, yes: contact the police. That’s going to go well: “I saw this on your computer, and I got in touch with the police, and they suggested I have chat with you…” Young people love that sort of conversation, too. Oh, and exactly how sure are you that the police haven’t taken the details of the child and put them on a list somewhere? Yes, I’m exactly that sure, as well.

Now, don’t get me wrong: there are tools out there that are dangerous and can be misused, and some of them will be. By teenagers, children and young adults. People of this age aren’t always good at making choices, and they’re sensitive to peer pressure, and they will make mistakes. But this is not the way to go about addressing this. We need to build trust, treat young people with respect, discuss choices, while encouraging careful research and learning. Hacking – the good type – can lead to great opportunities.

Alternatively, we can start constraining these budding security professionals early, and stop them in their tracks by refusing to let them use the Internet. Or phone. Or computers. Or read books. Actually, let’s start there. Let’s just not teach children to read: we’ll definitely be safe then (and there’s no way they’ll teach themselves, resent our control and turn against us: oh, no).

7 tips for kicking off an open source project

It’s not really about project mechanics at all

オープンソースプロジェクトを始める7つのアドバイス

I’m currently involved – heavily involved – in Enarx, an open source (of course!) project to allow you run sensitive workloads on untrusted hosts.  I’ve had involvement in various open source projects over the years, but this is the first for which I’m one of the founders.  We’re at the stage now where we’ve got a fair amount of code, quite a lot of documentation, a logo and (important!) stickers.  The project should hopefully be included in a Linux Foundation group – the Confidential Computing Consortium – so things are going very well indeed.  We’re at the stage where I thought it might be useful to reflect on some of the things we did to get things going.  To be clear, Enarx is a particular type of project: one that we believe has commercial and enterprise applications.  It’s also not mature yet, and we’ll have hurdles and challenges along the way.  What’s more, the route we’ve taken won’t be right for all projects, but hopefully there’s enough here to give a few pointers to other projects, or people considering starting one up.

The first thing I’d say is that there’s lots of help to be had out there.  I’d start with Opensource.com, where you’ll find lots of guidance.  I’d then follow up by saying that however much of it you follow, you’ll still get things wrong.  Anyway, here’s my list of things to consider.

1. Aim for critical mass

I’m very lucky to work at the amazing Red Hat, where everything we do is open source, and where we take open source and community very seriously.  I’ve heard it called a “critical mass” company: in order to get something taken seriously, you need to get enough people interested in it that it’s difficult to ignore. The two co-founders – Nathaniel McCallum and I – are both very enthusiastic about the project, and have spent a lot of time gaining sponsors within the organisation (you know who you are, and we thank you – we also know we haven’t done a good enough job with you on all occasions!), and “selling” it to engineers to get them interested enough that it was difficult to stop.  Some projects just bobble along with one or two contributors, but if you want to attract people and attention, getting a good set of people together who can get momentum going is a must.

2. Create a demo

If you want to get people involved, then a demo is great.  It doesn’t necessarily need to be polished, but it does need to show that what you’re doing it possible, and that you know what you’re doing.  For early demos, you may be talking to command line output: that’s fine, if what you’re providing isn’t a UI product.  Being able to talk to what you’re doing, and convey both your passion and the importance of the project, is a great boon.  People like to be able to see or experience something, and it’s much easier to communicate your enthusiasm if they have something that’s real which expresses that.

3. Choose a licence

Once you have code, and it’s open source, you want other people to be able to contribute.  This may seem like an unimportant step, but selecting an appropriate open source licence[1] will allow other people to contribute on well-understood and defined terms, making it easier for them, and easier for the organisations for which they work to allow them to be involved.

4. Get documentation

You might think that developer documentation is the most important to get out there – otherwise, how will other people get involved and coding?  I’d disagree, at least to start with.  For a small project, you can probably scale to a few more people just by explaining what the code does, what it should do, and what’s missing.  However, if there’s no documentation available to explain what it’s for, and how it’s going to help people, then why would anyone bother even looking at it?  This doesn’t need to be polished marketing copy, and it doesn’t need to be serious, but it does need to convey to people why they should care.  It’s also going to help you with the first point I mentioned, attaining critical mass, as being able to point to documentation, use cases and the rest will help convince people that you’ve thought through the point of your project.  We’ve used a github wiki as our main documentation hub, and we try to update that with new information as we generate it.  This is an area, to be clear, where we could do better.  But at least we know that.

5. Be visible

People aren’t going to find out about you unless you’re visible.  We were incredibly lucky in that just as we were beginning to get to a level of critical mass, the Confidential Computing Consortium was formed, and we immediately had a platform to increase our exposure.  We have Twitter account, I publish articles on my blog and at Opensource.com, we’ve been lucky enough to have the chance to publish on Red Hat’s now + Next blog, I’ve done interviews the the press and we speak at conferences wherever and whenever we can.  We’re very lucky to have these opportunities, and it’s clear that not all these approaches are appropriate for all projects, but make use of what you can: the more people that know about you, the more people can contribute.

6. Be welcoming

Let’s assume that people have found out about you: what next?  Well, they’re hopefully going to want to get involved.  If they don’t feel welcome, then any involvement they have will taper off soon.  Yes, you need documentation (and, after a while, technical documentation, no matter what I said above), but you need ways for them to talk to you, and for them to feel that they are valued.  We have Gitter channels (https://gitter.im/enarx/), and our daily stand-ups are open to anyone who wants to join.  Recently, someone opened an issue on our issues database, and during the conversation on that thread, it transpired that our daily stand-up time doesn’t work for them given their timezone, so we’re going to ensure that at least one a week does, and we’ve assured that we’ll accommodate them.

7. Work with people you like

I really, really enjoy meeting and working with the members of Enarx project team.  We get on well, we joke, we laugh and we share a common aim: to make Enarx successful.  I’m a firm believer in doing things you enjoy, where possible.  Particularly for the early stages of a project, you need people who are enthusiastic and enjoy working closely together – even if they’re separated by thousands of kilometres[2] geographically.  If they don’t get on, there’s a decent chance that your and their enthusiasm for the project will falter, that the momentum will be lost, and that the project will end up failing.  You won’t always get the chance to choose those with whom you work, but if you can, then choose people you like and get on with.

Conclusion – “people”

I didn’t realise it when I started writing this article, but it’s not really about project mechanics at all: it’s about people.  If you read back, you’ll find the importance of people visible in every tip, even including the one about choosing a licence.  Open source projects aren’t really about code: they’re about people, how they share, how they work together, and how they interact.

I’m certain that your experience of open source projects will vary, and I’d be very surprised if everyone agrees about the top seven things you should do for project success.  Arguably, Enarx isn’t a success yet, and I shouldn’t be giving advice at this stage of our maturity.  But when I think back to all of the open source projects that I can think of which are successful, people feature strongly, and I don’t think that’s a surprise at all.


1 – or “license”, if you’re from the US.

2 – or, in fact, miles.

 

オープンソースプロジェクトを始める7つのアドバイス

プロジェクト手法ではなく…

私は今Enarxプロジェクトに関わっています。とても深く、です。すでにご存知かもしれませんが、これはオープンソースのプロジェクトで、信頼できないホスト上で機密性の高いワークロードの実行を可能にするプロジェクトです。

 

何年もオープンソースプロジェクトに関わってきましたが、このプロジェクトで初めて私は共同創立者となりました。

私たちは現状、コードや文書を十分用意し、ロゴもステッカーも(これ重要!)用意できている段階です。

 

プロジェクトはLinux Foundationグループ(Confidential Computing Consortium)に含まれるはずなので、順調です。さらにプロジェクトを加速させるためにも内容に関してもお伝えしていったほうがいいでしょう。はっきりさせておくと、Enarxは商用とエンタープライズアプリケーションになるプロジェクトです。十分には成熟しておらず、まだまだハードルやチャレンジがあるかもしれません。さらに言うと、私たちの歩んできた道は全てのプロジェクトも当てはまらないかもしれませんが、他のプロジェクトやこれからプロジェクトを始めようとする人への指針になればと思っています。

 

ここまで来るにはたくさんのサポートがあったことをまずお伝えします。

私はOpenSource.comから始めましたが、ここではたくさんのガイドが載っています。それに従っても間違ってしまうこともあるかもしれません。ただ、以下に考慮すべき点を挙げておきます。

 

1 クリティカルマスを目標に

 

私は幸いにもRed Hatと言う素晴らしい職場で働いています。ここでは全てのものがオープンソースですし、オープンソースとそのコミュニティを非常に重要だと考えています。そこで「クリティカルマス」企業と言うものを耳にしました。物事を実際に行っていくには十分な人々の関心が必要で、人々が無視できないものとする必要があるということです。共同創立者のNathaniel McCallumと私はプロジェクトに情熱的で、組織内でスポンサーを得ることに時間をかけました。(誰のことだかわかりますよね、皆さんに感謝です!)そしてエンジニア達に「売り込み」をして惹き込み、プロジェクトが止まれなくなるくらいほどにしました。

プロジェクトのいくつかは一人二人の貢献者しか得ることができずもたついてしまいますが、人々の興味を惹きつけるには、どんどん進めてくれる、ある程度の人数を集めることが必須なのです。

 

2 デモ

 

人々を巻き込みたければデモをすると良いでしょう。洗練されている必要はなく、しようとしていることが実現可能であること、あなたが成し得たいことを示さなければいけません。初期段階のデモではコマンドラインの出力だけでしょうが、UIプロダクトを提供するのでなければ、それでもいいんです。成し遂げようとすることと情熱、プロジェクトの大切さを伝えることが有益なのです。人は何かを「見たい」「体験したい」ので、形にしてやる気を見せることが近道なのです。

 

3 ライセンスを選ぶ

コードをオープンソースで作ると、他の人にも貢献してもらいたくなるでしょう。これはあまり重要ではなく、正しいオープンソースのライセンスを選択することが他の人の貢献度を高め、定義された用語の理解を深め、その貢献する人働いている組織とその人たち自身の貢献するハードルを下げるのです。

 

4 文書作成

 

開発者文書が最重要だと考えるかもしれません。それなければどうやって人が貢献してコードを書くことができるでしょうか。

 

初めのうちは必要ないと思っています。小さなプロジェクトではコードが何をするものか、何をさせたいか、何が欠けているかいるか、の説明をすることで何人かの人を巻き込むことができます。

しかしコードが何をするものでどう便利か説明する文書がないのに、どうやってたくさんの人が時間を割いてくれるでしょうか。

 

文書といっても、ちゃんとしたマーケティング用のものだったり正式なものである必要はなくて、どうしてそれをしなくてはいけないかと皆さんに伝えるものでなければいけません。

これは一番目のポイント、クリティカルマスに注力することにも通じています。文書、ユースケースを示すことで、「ポイント」でプロジェクトが実現したいことに説得力を持たせるのに役立ちます。

 

私たちはgithubウィキをメインの文書置き場にしていて、作成と同時にアップデートしています。これはもう少し改善できるかと思います。

 

5 見えるプロジェクト

 

プロジェクトがちゃんと見える状態でないと見つけてもらえません。私たちのプロジェクトはとてもラッキーで、Confidential Computing Consortiumができた上にそこで見せられるだけのプラットフォームをすぐに作ることができたので、クリティカルマスに届く状態です。

 

Twitterのアカウントもあり(@enarxproject)このブログOpensource.comで記事も出しています。Red Hatのhttps://next.redhat.com/にてブログを出す機会にも恵まれ、プレスのインタビューも受けましたし出来るだけカンファレンスでも講演しています。私たちにはこのような良い機会がありましたが、全てのプロジェクトに適切なアプローチではないかもしれません。しかし知ってもらうことで、もっとたくさんの人々に貢献してもらえます。

 

6 歓迎しましょう

世間に知って頂けたとしましょう。次は何ができるでしょうか。そう、皆さんにプロジェクトに参加したいと思って頂きたいですよね。歓迎してもらえなければその参加数は少なくなって行きます。また上の方で私が何を言ったかに関わらず、しばらくすると技術文書も必要になります。そしてその人たちがあなたと話し合う方法が必要ですね。そうすることで評価されていると感じますから。

 

私たちの場合、Gitter(https://gitter.im/enarx/)で、毎日のスタンドアップ会議には参加したい人がみんな参加できます。最近ではそ課題データベース(https://github.com/enarx/enarx/issues)をGithubに作成しタコとで、スレッドの会話でタイムゾーンがあることから毎日のスタンドアップ会議の時間が合っていないことが明らかになりました。ので、会議の数を少なくとも週一とする配慮をしたのです。

 

7 仲の良い人と活動しましょう

 

私はとてもとてもEnarxプロジェクトチームのみんなと働くことが楽しいです。楽しく過ごし、冗談をかわし、笑って、共通の目標をシェアしています。Enarxの成功のためです。出来るだけ楽しんですること、それが大切だと思います。特にプロジェクトの初期段階では情熱的な人と楽しく仕事できる人が必要です。例えその人が地理的には数千キロ(マイル?)離れた場所にいても、です。そのように参加できなければ情熱もどんどん先細ってくるでしょうし勢いも失われ、プロジェクトは失敗に終わるでしょう。一緒に活動する人は選べるわけではないでしょうが、できればあなたの仲が良い人を選びましょう。

 

結論:「人」です。

 

この記事を書き始めるまでは気づきませんでしたが、全くプロジェクト手法が問題ではないのです。

 

人、です。

 

読み返せばどのアドバイスにも人の大切さが述べてあり、ライセンスの選び方にも、です。オープンソースプロジェクトとはコードではないのです。人なのです。どのようにシェアし、一緒に活動し交流するかなのです。

 

オープンソースプロジェクトはそれぞれ異なるものでしょうから、この7つのアドバイスが全て当てはまることはないでしょう。間違いなくEnarxはまだ成功と言い切れるものではありませんので、今の段階でこのようなアドバイスをすべきでないのかもしれません。しかし成功してきた今までのオープンソースプロジェクトを思い起こすと、やはり人と言うものはとても大切なのです。

 

元の記事:https://aliceevebob.com/2019/12/17/7-tips-for-kicking-off-an-open-source-project/

2019年12月7日 Mike Bursell

 

タグ:オープンソース