Enterprise Guide to Winding Down an Open Source Project



  • When it comes tolaunching an open source project, free information abounds online, on topics ranging from picking the right license to building a community. But what about when an organization needs to shutter or move away from an unneeded project? There are many complexities to handling this situation correctly, and many companies with successful open source programs plan for the end of a project even before launching one. Now, The Linux Foundation has published a free online guide for the enterprise examining the various considerations:Winding Down an Open Source Project.

    :undefined:“:undefined:By shutting down a project gracefully or by transitioning it to others who can continue the work, your enterprise can responsibly oversee the life cycle of the effort,:undefined:”:undefined: the guide notes. :undefined:“:undefined:In this way, you can also set proper expectations for users, ensure that long-term project code dependencies are supported, and preserve your company:undefined:’:undefined:s reputation within the open source community as a responsible participant.:undefined:”:undefined:

    The free guide includes sound advice on the following topics:

    1. Life cycle planning for your open source project
    2. What does a dead open source project look like?
    3. Why plan for the end of a project, before you even launch it?
    4. Deciding when to end or pull out of a project
    5. How to end an open source project

    You:undefined:’:undefined:ll also find direct advice from open source experts in the guide. Contributors include: Guy Martin, Director of Open at Autodesk, Autodesk; David A. Wheeler of Core Infrastructure Initiative (CII); Jared Smith, Open Source Community Manager, Capital One; Christine Abernathy, Open Source Developer Advocate, Facebook; and Chris Aniszczyk, COO of Cloud Native Computing Foundation.

    :undefined:“:undefined:When you:undefined:’:undefined:re starting your project, you:undefined:’:undefined:re trying to get people to trust you and allay their fears about joining the project and using your code,:undefined:”:undefined: David Wheeler notes, in the guide. :undefined:“:undefined:Later, if you say, :undefined:‘:undefined:Hey, this project:undefined:’:undefined:s going to go away soon,:undefined:’:undefined: that is not going to help with trust. Instead, you should say you:undefined:’:undefined:re going to do your best to make it work out if it will ever be ended, and that you promise not to just drop users. Tell them you:undefined:’:undefined:ll let them know what is happening at each step. Give them time to transition, and work on ways to help with the transition. That can be very helpful.:undefined:”:undefined:

    :undefined:“:undefined:It doesn:undefined:’:undefined:t happen all the time, but in the past with one of our projects we moved it over to a different company,:undefined:”:undefined: Abernathy noted, in discussing Facebook:undefined:’:undefined:s practices. :undefined:“:undefined:We don:undefined:’:undefined:t have any hard and fast rules about doing this. Typically, we:undefined:’:undefined:ll just move it to a different organization. When it comes to moving within groups, we sort of shop around internally and find out whether it is still being used by someone. With our open source projects, we strive toward internal adoption. So, it might be used by an entirely different team. If they are willing to maintain it, then we move it to a different team, and that:undefined:’:undefined:s very easy. That just means changing a label somewhere where it says who:undefined:’:undefined:s the owner.:undefined:”:undefined:

    Are you interested in more good advice? Check out the free online guide today. Additionally, The Linux Foundation andThe TODO Group (Talk Openly Develop Openly) have published an entire collection of enterprise guides to assist in developing open source programs and understanding how best to work with open source tools.The guides are available for free, and they cover everything fromHow to Create an Open Source Program toStarting an Open Source Project.

    The postEnterprise Guide to Winding Down an Open Source Project appeared first onThe Linux Foundation.

    https://www.linuxfoundation.org/blog/free-guide-winding-open-source-project/





  • Make ISO from DVD

    In this case I had an OS install disk which was required to be on a virtual node with no optical drive, so I needed to transfer an image to the server to create a VM

    Find out which device the DVD is:

    lsblk

    Output:

    NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 465.8G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 464.8G 0 part ├─centos-root 253:0 0 50G 0 lvm / ├─centos-swap 253:1 0 11.8G 0 lvm [SWAP] └─centos-home 253:2 0 403G 0 lvm /home sdb 8:16 1 14.5G 0 disk /mnt sr0 11:0 1 4.1G 0 rom /run/media/rick/CCSA_X64FRE_EN-US_DV5

    Therefore /dev/sr0 is the location , or disk to be made into an ISO

    I prefer simplicity, and sometimes deal with the fallout after the fact, however Ive repeated this countless times with success.

    dd if=/dev/sr0 of=win10.iso

    Where if=Input file and of=output file

    I chill out and do something else while the image is being copied/created, and the final output:

    8555456+0 records in 8555456+0 records out 4380393472 bytes (4.4 GB) copied, 331.937 s, 13.2 MB/s

    Fin!

    read more
  • Recreate postrgresql database template encode to ASCII

    UPDATE pg_database SET datistemplate = FALSE WHERE datname = 'template1';

    Now we can drop it:

    DROP DATABASE template1;

    Create database from template0, with a new default encoding:

    CREATE DATABASE template1 WITH TEMPLATE = template0 ENCODING = 'UNICODE'; UPDATE pg_database SET datistemplate = TRUE WHERE datname = 'template1'; \c template1 VACUUM FREEZE;

    read more
});