Will JavaScript type annotations kill TypeScript?
The creators of Svelte and Turbo 8 both dropped TS recently saying that "it's not worth it".
Yes: If JavaScript gets type annotations then there's no reason for TypeScript to exist.
No: TypeScript remains the best language for structuring large enterprise applications.
TBD: The existing user base and its corpensource owner means that TypeScript isn’t likely to reach EOL without a putting up a fight.
I hope they both die. I mean, if you really need strong types in the browser then you could leverage WASM and use a real programming language.
I don’t know and I don’t care.
Tech Life

3 Strategies for Better Open Source Support

The use of Open Source Software (OSS) has become so entrenched throughout the world-wide technological infrastructure that any organization relies on at least some of its components in order to remain competitive and profitable. Here is how to make it fruitful for the creator as well.
Oct 2nd, 2019 8:44am by
Featued image for: 3 Strategies for Better Open Source Support

The Linux Foundation sponsored this post.

Dr. Jerry Cooperstein
Jerry first began working with computers in 1969, and has been working with Linux since 1994, developing and delivering training in both the kernel and userspace. He has overall responsibility for all training content at The Linux Foundation. For over two decades as a theoretical nuclear astrophysicist at universities and national laboratories in the U.S. and in Europe, Jerry developed state-of-the-art high-performance simulation software on many kinds of supercomputers and taught at both the undergraduate and graduate level. Jerry joined the Linux Foundation in 2009 as the training program director. He lives in Wisconsin.

The use of open source software (OSS) has become so entrenched throughout the world-wide technological infrastructure that any organization relies on at least some of its components in order to remain competitive and profitable.

Using OSS is not effortless or painless; coherent strategies have to be adopted to handle matters such as:

  • Understanding, choosing and respecting the appropriate licensing.
  • Learning how to work productively and responsibly with the development community associated with the areas with which an organization needs to interface.
  • Adequate and well-trained staff has to be assigned to handle such responsibilities, including getting engineers oriented in proper methods. Getting it right at the beginning is important.

Our focus here, however, will be on one often-cited area of concern: the necessity of engaging responsive high-quality technical support, and its long term availability. As a means to that end, maintaining up-to-date training is critical.

However, much work needs to be done for both users and technical support personnel to take full advantage of OSS resources for training, documentation and support. They may use methods, for example, that may not conform to their usual orientation and experience.

Most companies and other organizations have long been accustomed to the support that comes with proprietary products (think Sun, Oracle, Microsoft, etc). The usual situation contains multiple potential varieties of support, which differ in level, turn-around time, pricing, etc. In most cases, there are a few alternative choices for competent support for a proprietary product.

And usually, some kind of technical support is likely to be bundled into the cost of the product. With open source it is different and there is no “one size fits all” approach that will work with all concerns. Here are the three support strategies to consider:

  • First and most importantly, have key personnel (usually developers) join the community ecosystems built around the products they use. These people can be developers, reviewers, testers or staffers who even just keep up with ongoing discussions in various forums. It also means being aware of and using all the freely available online documentation that exists, preferably from the project itself.
  • A second (and complementary) strategy is to directly support the project sponsor. This can mean donating to individuals or groups of developers. It is best if it is not too heavily coupled with requests for features that may not be more generally needed. This works better if also combined with review and testing.
  • Third, many companies contract for commercial support. For example, one can subscribe to Red Hat Enterprise Linux and pick a level of support. Even a no-cost Linux distribution, such as Ubuntu, may offer paid technical support. Such arrangements are not fundamentally different than getting support for a proprietary product, but the open nature of the product can make communication much more of a two-way street.

Note that one can also work with alternative suppliers of technical support; there are far more competitive choices with open source software. Such suppliers may be limited to one or a few products, or can service a more general and comprehensive consulting role.

The best approach incorporates as much expertise as possible internally. Staff should be encouraged (even better, mandated) to join OSS developer communities as part of their normal workflow and paid work. Such liaison personnel can keep their eyes and ears close to a project and not only react to changes, but also see what is coming up in the future and anticipate any changes required.

Of course, the proper strategy will vary, depending on factors, such as the size and location of your operation. Smaller organizations, for example, may have more trouble growing expertise and support internally.

Because experienced and talented Linux-skilled workers are in high demand today, attempts to hire them often fail, especially if the location is not ideal geographically and/or in the sense there is not a pool of local talent. In fulfilling that need, the Linux Foundation offers training in many areas using a mix of free/paid and self-paced/instructor-led materials. The Linux Foundation course maintainers and instructors also have relevant experience and deep ties to the associated development and user communities.

This means companies also have to drop any traditional bias against the use of remote workers.  Most open source software is developed by often widely dispersed teams and individuals who communicate in many different forms.

One needs to break down the wall between the software and technical support to succeed with open source software. This requires many to adopt a new way of thinking. OSS is only going to become an even larger fraction of the code base for virtually every software product and there is no substitute for breaking the producer/consumer barrier and cultivating internal knowledge and experience.

Feature image by from Pixabay.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.